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NUMERICAL AERODYNAMIC SIMULATION PROGRAM LONG HAUL COMMUNICATIONS PROTOTYPE 


Bohden K. Cmaylo and Foo Lee* 
Ames Research Center 


SUMMARY 


This document is a report of the Numerical Aerodynamic Simulation (NAS) Long 
Haul Communications Prototype (LHCP). It describes the accomplishments of the LHCP 
group, presents the results from all LHCP experiments and testing activities, makes 
recommendations for present and future LHC activities, and evaluates the remote 
workstation accesses from Langley Research Center, Lewis Research Center, and 
Colorado State University to Ames Research Center. The report is the final effort 
of the Long Haul (Wideband) Communications Prototype Plan (PT-1 133-02-N00) , 

3 October 1985, which defined the requirements for the development, test, and opera- 
tion of the LHCP network and was the plan used to evaluate the remote user bandwidth 
requirements for the Numerical Aerodynamic Simulation Processing System Network. 


1. INTRODUCTION 


This report consists of four sections and six appendixes. A short description 
of each follows: 

Section 1: An overview of the purpose and scope of the Long Haul (Wideband) 

Communications Prototype (LHCP) network. 

Section 2: Referenced documents used in the preparation of this report. 

Section 3: Summary of the objectives of the LHCP and the results of each 
objective, and the accomplishments and recommendations of the LHCP group. 

Section 4: The technical report, which describes in detail how the objectives 

were accomplished; this section discusses the LHCP configuration, experiments, and 
resource requirements. 

Appendix A: List of acronyms used in this report. 

Appendix B: Description of the LHCP hardware and Electronics Laboratory test- 

ing equipment. 

Appendix C: Reports of the LHCP experiments. 


*General Electric Company, San Jose, California. 
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Appendix D: Monthly reports received from the remote sites by the LHCP group. 

Appendix E: Problem history and resolution during the course of establishing 

the LHCP. 


Appendix F: Contributors to the Long Haul Communications Prototype Report. 


1 . 1 Purpose 

The purpose of this document is to report the steps taken in the development, 
test, and operation of the Long Haul (Wideband) Communications Prototype (LHCP). 

(See Numerical Aerodynamic Simulation (NAS) Projects Office ref. 1 for the LHCP 
Plan, which proposed the initial design and direction of the LHCP network. Refer- 
ences are listed in Section 2, Applicable Documents, of this paper.) This LHCP 
network was designed to evaluate the remote user bandwidth requirements for the NAS 
Processing System Network (NPSN), and to initiate access to the NPSN Initial Oper- 
ating Configuration (IOC) by remote computational fluid dynamics users. (See NAS 
Projects Office ref. 2 for a more detailed description of the IOC.) The NPSN is 
being developed under the direction of the NAS Projects Office of the National Aero- 
nautics and Space Administration (NASA), Ames Research Center, Moffett Field, 
California. 

This report defines and evaluates the remote workstation accesses to Ames 
Research Center (ARC) from the NASA Langley Research Center (LaRC), Hampton, 
Virginia; the NASA Lewis Research Center (LeRC), Cleveland, Ohio; and Colorado State 
University (CSU), Fort Collins, Colorado. 


1.2 Scope 

The LHCP effort was used to establish computer communications between ARC and 
the remote sites, and to evaluate the Vitalink VB/1 bridge boxes, TransLAN software, 
communications equipment, communications links, and the bandwidth requirements of 
the remote users. 

The LHCP effort consisted of using NAS workstations at LaRC and LeRC, and a 
non-NAS workstation at CSU, all of which are connected to their local area networks 
via Ethernets, to access the NPSN via a gateway host at ARC. 

Three experiments— the user bandwidth experiment, the hardware experiment, and 
the transmission control protocol/internet protocol (TCP/IP) tuning experiment — were 
used to evaluate the LHCP. The report on the user bandwidth experiment can be found 
in NAS Projects Office reference 8, and the reports on the hardware and TCP/IP 
experiments are presented in appendix C. 

The results of the experiments were used to establish the remote user needs 
within the development of the LHC subsystem. The LHCP provided NAS personnel with 
valuable experience in wideband communications and computer networking. This 
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experience aided in the design, development, implementation, and operation of the 
LHC subsystem portion of the Integrated Support Processor Complex (ISPC). (See NAS 
Projects Office ref. 4 for a more detailed description of the ISPC.) 

The LHCP effort (i.e., the prototype as a whole) was divided into two phases, 
which allowed early user involvement in the development of the LHCP network (i.e., 
the wideband communications links). 

1. The first phase used remote NAS workstations (Silicon Graphics, Inc.'s 
(SGI) IRIS 1500s, which were upgraded to 2500s), a remote non-WAS workstation 
(Sun 160 workstation), and the NAS Ethernet network via a VAX 11/780 (the Cray 
gateway) to access the Cray X-MP/12. This phase allowed LHCP testing to start 
before the NAS Cray-2 was connected to the NPSN. (See NAS Projects Office ref. 3 
for a description of the IRIS workstation, and NAS Projects Office ref. 2 for a 
description of the Cray.) 

2. The second phase used both NAS and non-NAS type remote workstations to 
access the Cray-2 when it was operational and connected to the NPSN. 

These phases did not include additional bandwidth capabilities, such as T1 data 
rate (1.544 megabits per second, Mbps), since that capability was not available for 
use at that time. The LHCP high-speed wideband T1 network will be supplied by the 
NASA Program Support Communications Network (PSCN) when it becomes available. The 
PSCN contract was awarded to Boeing Computer Services on 1 April 1985. A commercial 
communications network was used in the early phases of this experiment. Boeing/RCA 
supplied the interim service at 224 kbps; the 56-kbps line was obtained from 
Boeing/AT&T. All NASA communications requests for resources, such as NASA PSCN 
circuits and interim circuits, were channeled through the Marshall Space Flight 
Center. The circuits were transferred to PSCN administration and control on 1 April 
1986 . 


2. APPLICABLE DOCUMENTS 


Although the LHCP plan is not a controlled document, there was an effort to 
make it consistent with the other documents governing the NAS program. The applica- 
ble NAS documents are listed below. 

1. PT-1 133-02-NOO Numerical Aerodynamic Simulation Program 

Long Haul (Wideband) Communications Prototype Plan for Remote 
Workstation Access to ARC from LaRC, LeRC, and CSU. 

3 October 1985 

2. PP-1 100-01-C01 Numerical Aerodynamic Simulation Program 

Development Plan for the NPSN Initial Operating Configuration 
24 April 1985 
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3. PP-1 126-OO-NOO Numerical Aerodynamic Simulation Program 

User Interface Prototype Development Plan 
14 May 1984 

4. RFP2-31373(DHC) Integrated Support Processing Complex (ISPC) 

Numerical Aerodynamic Simulation 
Processing System Network (NPSN) 

5. PT-1 133-0 1-N00 Numerical Aerodynamic Simulation Program 

Long Haul Communications Prototype Experiments Plan 
24 June 1985 


6. TBD 


7. TBD 


8. TBD 


Numerical Aerodynamic Simulation Program 

Operational Policy and Procedures for Remote Workstations 

26 February 1986 

Program Configuration Control Board Recommended 25 March 1986 
Numerical Aerodynamic Simulation Program 

Long Haul Communications Prototype Transition to Operations 
Plan 

21 April 1986 

Numerical Aerodynamic Simulation Program 

Long Haul Communications Prototype Experiments Results 

(to be determined) 


3. EXECUTIVE SUMMARY 


This summary consists of three subsections. The first subsection sets forth 
the initial objectives of the LHCP and discusses how each objective was satisfied. 
The second subsection reports the accomplishments of the LHCP group in establishing 
the network. The third subsection presents the recommendations of the LHCP group as 
they relate to future NAS Projects Office activities dealing with long-haul 
communications. 


3.1 Initial Objectives and Results of Objectives 

The results of the initial objectives, as defined in NAS Projects Office 
reference 1, are summarized below after each of the stated initial objectives. The 
initial objectives were as follows. 

1 . Establish and evaluate the LHCP wideband network design. The LHCP wideband 
network design that was established consisted of three remote sites: LaRC, LeRC, 

and CSU. Langley Research Center and LeRC are communicating with ARC over 224-kbps 
satellite links provided by Boeing/RCA. Colorado State University is communicating 
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with ARC over a 56-kbps terrestrial link provided by Boeing/AT&T. Vitalink VB/1 
bridges and related TransLAN software are used to connect the remote sites with 
ARC. The evaluations of the Vitalink VB/1 bridges have shown that their use is a 
feasible method of meeting long-haul communications requirements and providing long- 
haul communications capabilities to remote sites at those data transmission rates. 
The LHCP hardware experiment consisted of evaluating the Vitalink VB/1 bridge boxes, 
learning how to use the TransLAN software, the satellite delay simulator, modems, 
and other communications equipment; and evaluating the communications links. Sev- 
eral hardware tests were designed to determine workstation data transmission charac- 
teristics and to measure data transfer rates of various sizes between worksta- 
tions. One test evaluated transmissions between workstations that were on the same 
Ethernet. Other tests evaluated transmissions between workstations connected to two 
separate Ethernets but bridged together with VB/ls over a simulated communications 
link and over the 56- and 224-kbps communications links. The complete report on the 
hardware experiments is presented in appendix C. 

2. Initiate early remote user activity. The LHCP effort initiated early 
remote-user activities by allowing the remote users from LaRC, LeRC, and CSU to 
access NPSN resources before IOC and the establishment of the LHC subsystem. 

3. Evaluate and establish the LHCP bandwidth requirements. The LHCP bandwidth 
experiment as defined in NAS Projects Office reference 5 started in the third quar- 
ter of 1985, before the NPSN IOC was fully operational, and continued over several 
months. The purpose of this experiment was to provide experience in high-speed 
communications, initially at 56 and 224 kbps, and, it was hoped, at 1.544 Mbps 
(which did not occur), and to provide experience with remote communications 
capabilities. Emphasis was on the evaluation of remote NAS workstation 
communications from both LaRC and LeRC to ARC and remote non-NAS workstation 
communications from CSU to ARC. The results from the bandwidth experiment will be 
used to help establish the bandwidth requirements for future remote sites wishing to 
get on the LHC subsystem. (See NAS Projects Office ref. 5 for a detailed 
description of the LHCP user bandwidth experiment plan.) 

4. Generate cooperative user involvement. The LHCP effort was also a means by 
which to generate cooperative user involvement. The remote users (specifically the 
site/system administrators) were involved from the very beginning of the implementa- 
tion of the LHCP wideband communications network and installation of the Vitalink 
and related communications equipment. The LHCP could not have been implemented 
successfully without the cooperative involvement of the administrators. 

5. Provide user feedback through use of NAS workstations (IRIS 1500/2500) from 
remote-user sites. NAS workstations (IRIS 1500/2500) were shipped to LaRC and LeRC 
for use from these remote sites to access the NPSN resources. Feedback regarding 
the use of the NAS workstations and access to the NPSN resources was provided by the 
remote users in form of monthly reports and trouble calls to the LHCP group. The 
reports and trouble calls will be handled by the NAS Projects Office User Services 
in the future. 
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6. Provide user feedback through use of a non-NAS workstation (Sun 160) from a 
remote user site. A non-NAS workstation (Sun 160) was used from CSU to access the 
NPSN resources. Feedbacks regarding the use of the non-NAS workstation and access 
to the NPSN resources was provided by the remote users in form of monthly reports 
and trouble calls to the LHCP group. The reports and trouble calls will continue to 
be handled by the NAS Projects Office User Services. 

7. Transfer knowledge and experience gained in working with PSCN and commer- 
cial communications services to the IOC. The knowledge and experience gained in 
working with the NASA PSCN, and commercial communications services have been trans- 
ferred to the LHC subsystem group. The LHC subsystem group has used and will con- 
tinue to use the knowledge to further develop the LHC subsystem for IOC implementa- 
tion. (A list of problems and experiences encountered during the LHCP is included 
in appendix E.) 

8. Transfer development resources (i.e., hardware and software) acquired to 

the IOC. The functional Vitalink VB/1 bridges communicating with LaRC, LeRC, and 
CSU were transferred to NAS Projects Office Operations. (See NAS Projects Office 
ref. 7 for a full description of the transition to operational activities.) The 
user services activities were transferred to NAS Projects Office User Services. 
Additional development resources (i.e., hardware and software) acquired during the 
LHCP including the LHC Electronics Laboratory, laboratory equipment, and 
communications equipment will be transferred to the LHC subsystem group or to the 
NAS Projects Office Operations or to both. 


3.2 Accomplishments 

The LHCP was concluded on 30 April 1986; the following had been accomplished. 

1. The LHCP development plan was written and approved on 3 October 1985 by the 
NAS Projects Office Engineering Review Board. The plan described the scope, activi- 
ties, and schedules of the prototype. (NAS Projects Office ref. 1.) 

2. This report on the LHCP development was written at the conclusion of LHCP 
activities. It noted modifications to the original plan to better document the 
actual activities of the LHCP. An executive summary, which included the accomplish- 
ments and recommendations of the LHCP group, was also included with the technical 
report. Appendixes were included that present the communication and testing hard- 
ware descriptions, LHCP experiment reports, remote monthly reports, and the LHCP 
problem history and resolution reports. 

3. The Vitalink boxes (VB/1 and CS/100) connected the remote sites to the 
NPSN. The Vitalink communication equipment interfaced to the LHCP communication 
circuits and joined the remote site Ethernets to the local NAS Processing System 
Ethernet subnetwork. A checkout list of equipment was designed to facilitate con- 
nections to NPSN from other remote sites. 
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4. Three remote sites were requested to participate in evaluating the LHCP: 

CSU, LaRC, and LeRC. The following describes the activities establishing the LHCP 
communication links with those sites. (a) A communication link was established via 
a 56-kbps AT&T circuit from ARC to CSU. The Vitalink box (VB/1) was first tested by 
the LHCP group, and then delivered to CSU on 22 July 1985. The circuit was acti- 
vated on 21 June 1985. The connection of the Sun workstation at CSU to the NPSN at 
ARC communication was established 2 August 1985. The long delay between circuit 
activation and data communication was due to a delay in delivery of the Data Service 
Unit (DSU) modems by Boeing, (b) A communication link was established via a 
224-kbps RCA Americom Satellite circuit from ARC to LaRC. The VB/1 was delivered to 
LaRC on 6 September 1985. The IRIS workstation at LaRC was on loan from the NAS 
Projects Office for this purpose and was received by LaRC on 6 September 1985. The 
satellite circuit was activated on 6 September 1985, and completely tested and 
released by RCA on 30 September 1985. The connection of the IRIS workstation at 
LaRC to the NPSN at ARC communication was established 10 October 1985. An upgrade 
from the IRIS 1500 model to an IRIS 2500 model was completed by LaRC on 5 February 
1986. (c) A communication link was established via a 224-kbps RCA Americom 

Satellite circuit from ARC to LeRC. The VB/1 was delivered to LeRC on 12 September 
1985. The IRIS workstation at LeRC was on loan from the NAS Projects Office for 
this purpose and was received by LeRC on 12 September 1985. The satellite circuit 
was activated on 16 September 1985, and completely tested and released by RCA on 

18 October 1985. The connection of the IRIS workstation at LeRC to the NPSN Network 
at ARC communication was established 18 October 1985. An upgrade from the IRIS 1500 
model to an IRIS 2500 model was completed by LeRC on 2 April 1 986 . 

5. The LHCP experiments plan was written and approved on 6 June 1985 by the 
NAS Projects Office Engineering Review Board. This plan described the user band- 
width experiments scope, schedule, and activities that were to take place between 
ARC, CSU, LaRC, and LeRC. This experiment was to evaluate user satisfaction with 
the LHCP remote circuits. A primary result of this experiment was to obtain infor- 
mation so that bandwidth requirements for future remote users could be evaluated 
(NAS Projects Office ref. 5). 

6. The user bandwidth experiment was partially completed. The experiment was 
successful for the CSU participants; however, in performing the LaRC user bandwidth 
experiment and the hardware experiment, it was discovered that the TCP/IP protocol 
used did not perform satisfactorily over satellite links, and that the maximum 
performance observed was approximately 10$ of the 224-kbps satellite bandwidth. 
Further experiments were canceled until either the problem is resolved or additional 
bandwidth requirements data are needed (NAS Projects Office ref. 8). 

7. The hardware experiment was designed to test various portions of the com- 
munication circuits of the LHCP. These tests primarily tested the Ethernet transfer 
rates to obtain a baseline, and Vitalink-to-Vitalink transfer rates with comparisons 
to the baseline. The baseline portion was completed; however, the full Vitalink-to- 
Vitalink tests are still in process. The results are presented in appendix C. 



8. A third experiment that was performed involved limited tuning of the TCP/IP 
protocol to observe improvements in satellite file transfer performance. A memo was 
written to describe the change from -10% to -75% bandwidth utilization. The final 
results are presented in appendix C. 

9. A fourth experiment that was performed involved a comparison of the TCP/IP 
protocol versus the Xerox Network Services (XNS) protocol. This test was requested 
by the workstation subsystem manager, Tom Lasinski. Completed in January 1986, 
these test results show that XNS performs better than TCP/IP. The final results are 
presented in appendix C. 

10. The LHC Electronics Laboratory was established, and test equipment for 
monitoring or repairing the communication links was purchased. Appendix B lists all 
test equipment and the equipment's functions. The LHC Electronics Laboratory and 
personnel were transitioned to the LHC subsystem development group at the conclusion 
of the LHCP. 

11. Two additional documents were written to complete the LHCP. (a) The first 
is a draft of the Numerical Aerodynamic Simulation Remote Workstations Operational 
Policy and Procedures for Remote Workstations. This document established initial 
recommendations to be followed by both NAS Projects Office and the remote sites to 
smooth workstation configurations and administration (NAS Projects Office refer- 
ence 6). And (b), the Long Haul Communications Prototype Transition to Operations 
Plan. This plan describes all LHCP activities and procedures and when and to whom 
these activities and procedures will be transferred (NAS Projects Office ref. 7). 


3.3 Recommendations 

Based on the results and knowledge gained during the LHCP effort, the LHCP 
group makes the following recommendations: 

1. Terrestrial circuits were observed to be more stable than satellite cir- 
cuits; therefore, if cost is not a major factor, terrestrial circuits would be 
preferred. 

2. Based on the results of the prototype experiments (NAS Projects Office 
ref. 8), a 56-kbps terrestrial circuit appears to be able to support one or two 

Sun 2.1 or IRIS 2500 workstations. Also, a 224-kbps satellite circuit was deemed to 
poorly support three or four IRIS 2500 workstations, whereas a 224-kbps terrestrial 
circuit was estimated to adequately support the same number of workstations. 

,3. The TCP/IP protocol on each host, as currently implemented, is not tuned 
for satellite performance. If satellite circuits are to be used, then the TCP/IP 
protocol must be tuned to account for the transport delay in satellite circuits. 

4. The Vitalink method of bridging Ethernets is a feasible way of linking 
remote sites; however, problems exist in maintaining NAS Projects Office control of 
the remote Ethernet network addresses on the remote sites. Other methods, such as 
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gateways, should be explored. Also, the Vitalink method may not be practical for 
bandwidths higher than 224 kbps. 

5. As remote users use the LHC network, it should be monitored by the LHC 
Electronics Laboratory to determine the performance and behavior of the link. For 
example, if the link is degrading or if the link is constantly used too lightly or 
heavily, then action should be taken to reconfigure the link. 


4. TECHNICAL REPORT 


The LHCP effort evaluated the capabilities for remote users to communicate with 
a Cray and the performance of the LHCP network via LHCP experiments. 


4.1 LHCP Configuration Changes 

4.1.1 Phase 1 test configuration and schedule.- The first phase of the LHCP 
effort used remote IRIS 1500/2500s, a remote Sun 160, an interim LHCP network (sup- 
plied by PSCN/Boeing/RCA/AT&T) , and the NAS Processing System Ethernet subnetwork to 
access the Cray X-MP/12 via the gateway host VAX. Figure 1 is a diagram of the LHCP 
configuration depicting remote workstation accesses to the Cray X-MP/12 via the NAS 
Processing System Ethernet subnetwork and gateway host VAX. 

This first phase of the remote NAS workstation test configuration allowed 
remote workstations to access and use the Cray X-MP/12 (running COS and accessed 
through CRINT) via the gateway host VAX. This test configuration used remote NAS 
workstations at LaRC and LeRC, and a Sun 160 at CSU, all of which were connected to 
their respective local area networks using Ethernets. Two remote NAS workstations 
were shipped, one to LaRC and the other to LeRC. 

A product offered by Vitalink Communications Corporation was used to interface 
each Ethernet to the satellite gateway. The Ethernet adapter was manufactured by 
Bridge Communications Inc. using the TransLAN software package developed by Vita- 
link. The hardware-software product combination was referred to as VB/1. The VB/1 
supported data rates up to 224 kbps and provided standard interfaces to Ethernets 
and satellite Earth terminals. A VB/1 was required at each Earth terminal loca- 
tion. At the time, the VB/1 did not support T1; however, it was planned to increase 
its capacity to this level. 

The Vitalink VB/ls and TransLAN software were delivered to ARC in April 1985 
and went through an extensive checkout and hardware testing by LHCP technicians. 

The Phase 1 test schedule was dependent on the availability of the 56-kbps 
terrestrial line to be installed by Boeing/AT&T and the 224-kbps satellite links to 
be provided via the PSCN by Boeing/RCA. 
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The first experiment involved the CSU site because its 56-kbps terrestrial line 
was installed before either of the 224-kbps satellite links was available. The 
56-kbps line between ARC and CSU was installed on 21 June 1985. The Vitalink VB/1 
and DSU modem equipment was delivered and installed at CSU on 26 July 1985. The 
56-kbps line testing between ARC and CSU was completed on 2 August 1985. Upon 
completion of the line testing, the actual remote bandwidth experiment from CSU 
began on 19 August 1985 and was completed on 30 August 1985. 

The ARC satellite link was ready on 21 August 1985. Loopback testing from ARC 
to ARC was performed over the subsequent 5 weeks, with the ARC satellite communica- 
tions scheduled to be available to LaRC and LeRC by 30 September 1985. 
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The 224-kbps LaRC satellite circuit was installed by RCA on 2 September 1985. 
The ARC-to-LaRC link was completed and tested by RCA on 20 September 1985. 
Computer-to-computer communications between ARC and LaRC was established by the LHCP 
group on 10 October 1985, 1 day after the ARC-LaRC circuit was turned over by RCA. 
The user bandwidth experiment began on 30 September 1985 at ARC and was completed at 
ARC on 4 October 1985. Preliminary results from testing of the LaRC-ARC link sug- 
gested that additional user bandwidth experiments be canceled because of problems 
pertaining to the TCP/IP protocol caused by satellite transport delay (refer to 
appendix C for further details). 

Similarly, the 224-kbps LeRC satellite circuit was installed by RCA on 16 Sep- 
tember 1985. The ARC-to-LaRC link was tested by RCA and completed on 18 October 

1985. Computer communications between ARC and LaRC was established by the LHCP 
group on 21 October 1985. The ARC-to-LeRC user bandwidth experiment was canceled 
due to the problem found during the LaRC user bandwidth experiment. 

4.1.2 Phase 2 test configuration and schedule The second phase of the LHCP 
used the remote workstations and the LHCP network to access the NAS Cray-2. Access 
to the LHCP network was via the LHC subsystem gateway on the ISPC, since the NPSN 
UNIX-like (Universal Timesharing System) on the ISPC became operational for remote 
users in January 1986. This configuration is closer to the operational IOC for 
remote access. (Note: The Cray-2 and ISPC were not vital equipment required in the 

completion of the early phase of the bandwidth experiment.) 

This second phase of the LHCP test configuration allowed the remote NAS work- 
stations at LaRC and LeRC, and the non-NAS workstation at CSU, to access and use the 
NAS Cray-2. The NAS Cray-2 was available for pilot use in the first quarter of 

1986. The simple effective protocol (SEP) was used to access the NAS Cray-2. 


4.2 LHCP Experiments 

The LHCP provided an opportunity to study the following remote-user needs in 
terms of response and performance during the above two phases of the LHCP effort. 

1 . Bandwidth requirements 

2. Access to transmission facility 

3. Large file transfers (1 to 40 MB) 

4. Distribution of file storage and use (remote versus NPSN file storage) 

5. Preprocessing of graphics at NPSN 

6. Workstation-to-workstation communications and data transfer 

4.2.1 Summary.- The LHCP effort consisted of four experiments: the user 

bandwidth experiment, the hardware experiment, the TCP/IP tuning experiment, and an 
XNS versus TCP/IP comparison test. 


*■ 
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1. The user bandwidth experiment evaluated the use of remote communications 
links between IRIS 1500/2500 and Sun 160 workstations and the NPSN resources to 
determine remote-user bandwidth requirements. The result of the user bandwidth 
experiment is documented in NAS Projects Office reference 8. 

2. The hardware experiment tested and analyzed the hardware and communications 
links. The results of the hardware experiment is documented in appendix C. 

3. The TCP/IP tuning experiment evaluated the protocol limitations, a result 
of the effect of satellite delays. The result of the TCP/IP tuning experiment is 
also documented in appendix C. 

4. The XNS versus TCP/IP test compared the transfer rates of the protocols 
over communication links with and without satellite delays. The result of the XNS 
versus TCP/IP tests is also documented in appendix C. 

The LHCP experiments described in this report were based on using Ethernets as 
the interconnecting media for Local Area Networks at LaRC, LeRC, and CSU. 

4.2.2 Experimental philosophy The experiments and tests followed the 
sequence outlined below. "Local site" refers to ARC and the "remote sites" refer to 
LaRC, LeRC, and CSU. 

1. The NAS Projects Office acquired Ethernet transceivers, Vitalink VB/1 
hardware and TransLAN software, and NAS workstations to connect to the Ethernets at 
LaRC, LeRC, and CSU. Colorado State University acquired a Sun 160 workstation 
independently . 

2. All the hardware and software at ARC underwent installation and acceptance 
testing. Local loopback testing was performed through the LHCP network to validate 
the transmit-and-receive paths of the LHCP network and associated equipment. 

3. After acceptance testing at ARC, the VB/ls and transceivers were shipped to 
LaRC, LeRC, and CSU; NAS workstations were sent to LaRC and LeRC. LaRC, LeRC, and 
CSU also performed loopback tests through the LHCP network using this equipment. 

4. End-to-end testing from remote workstations to the high-speed processor 
(HSP), which is described in the user bandwidth experiment, were conducted. Remote- 
to-local NAS workstation communications were also tested. 

5. Hardware experiments using different variations (configurations) of commun- 
ications equipment, computers, circuit rates, and transport delays were performed. 

6. Other experiments, such as tuning TCP/IP and an XNS versus TCP/IP compari- 
son were conducted when previous tests indicated a need for further investigation. 

The LHCP access and use of the NPSN resources were evaluated using NAS Projects 
Office supplied software. Vendor-supplied test equipment, test procedures, and 
diagnostic routines were used wherever possible. 
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4.2.2. 1 Hardware experiment objectives: The objectives for each of the five 

hardware experiments were as follows. 

1. To transfer data files of various lengths between two workstations con- 
nected to the same Ethernet (private Ethernet cable); to measure the time it 
required to transfer the file; and to determine the transfer rates. 

2. To transfer data files of various lengths between two workstations con- 
nected to two Ethernets (private Ethernet cables); to measure the time required to 
transfer the file; and to determine the transfer rates. VB/ls are introduced into 
the system for this test. Its objective is to make the same measurements as in 
Test 1, that is, to determine the data transfer characteristics when a pair of VB/ls 
was used to connect two physically separated Ethernets. For this test and all 
subsequent tests, the Digital Satellite Communications Simulator (DSCS) was used to 
connect the two VB/ls to establish a communication link; however, no transport 
delays were introduced for this test. The DSCS was used to simulate typical satel- 
lite delays. 

3. To make the same measurements as in test 2, however, the measurements taken 
between the two workstations included transport delays introduced via the DSCS. 

4. To make the same measurements as in test 2, but with bit error rates (BERs) 
injected into the communications link between the two VB/ls. A BER test set was to 
be connected at both ends of the DSCS to measure the BERs. (This test will be 
completed at a future time by the LHC subsystem group.) 

5. To make the same measurements as in test 3, but with BERs injected into the 
communications link between the two VB/ls. A BER test set was to be connected at 
both ends of the DSCS to measure the BERs. (This test will be completed at a future 
time by the LHC subsystem group.) 

When executed, each one of these tests generated a header message indicating 
the nature of the test, size of the file being transferred, the time it took to 
transfer the file, and the transfer rate. The appropriate hardware configuration 
was set up prior to the invocation of each test. The results, tabulated and 
plotted, appear in appendix C. 

4. 2. 2. 2 User bandwidth experiment measurement objectives: The experiment 

measurement objectives and the specifications of the measurement software being 
developed for the LHCP user bandwidth experiment are discussed briefly here and in 
more detail in the "Long Haul Communications Prototype Experiments Plan (NAS Pro- 
jects Office ref. 5). 

The formal objective of the LHCP user bandwidth experiment was to evaluate the 
services provided to remote users via two different communications links: one 

service at 56-kbps terrestrial and the other at 224-kbps satellite. Even though the 
evaluation of these two types of services was concerned with the actual end-to-end 
transfer rates achieved, it also focused on the subjective differences between the 
two as experienced by the remote users. In addition to evaluating the 
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communications bandwidth requirements of remote users, these experiments also pro- 
vided a structure within which NPSN (i.e., ARC) personnel can formally address com- 
munications issues and which permitted early user involvement. 

The bandwidth measurement was primarily concerned with file transfers and other 
activities between the remote sites and ARC. Access to a Cray was desirable but not 
necessary for this experiment. 

The results of this experiment will be given in more detail in NAS Projects 
Office reference 8. 

4. 2. 2. 3 Protocol tuning tests: Early (initial) measurements of data transfers 

between the remote workstation at LaRC and the gateway host VAX at ARC indicated 
rates far below the maximum bandwidth capacity. It was determined that some tuning 
of the TCP/IP protocol, such as varying the window size for the maximum buffer of 
outstanding data, was needed to see if any improvement in the data transfer rates 
could be obtained from the existing satellite link to LaRC. The software consisted 
of the same "netpush" program that was used in the hardware experiments, except for 
patches to the system kernel code to allow dynamic tuning of the various parameters 
needed to control the window size. 

An informal agreement between the NAS project at ARC and the Institute for 
Computational Applications in Science and Engineering (ICASE) project at LaRC was 
made to use dedicated time on the NAS AMELIA VAX and the ICASE VAX to perform the 
TCP/IP tuning tests. Appendix C contains the final results of the TCP/IP tuning 
tests . 

4. 2. 2. 4 XNS versus TCP/IP protocol comparison tests: Tests were also run to 

compare the effects of XNS versus TCP/IP protocols on data transfer rates. The 
tests consisted of comparing results of two identical IRISs running on the NAS 
network using the rep program, which uses the TCP/IP protocol, with the IRISs using 
the xcp program, which uses the XNS protocol. Appendix C contains the report of the 
TCP/IP-XNS tests. 


4.3 Resource Requirements 

4.3.1 Minimum requirements/conditions for testing.- The minimum resources and 
dependencies required in order to perform the LHCP experiments are itemized below. 

1. Communications network requirements: (a) 224-kbps data links between ARC 

and LaRC and also between ARC and LeRC supplied by PSCN/Boeing/RCA ; (b) 56-kbps data 
link between ARC and CSU provided via PSCN/Boeing/AT&T 

2. Workstation requirements: (a) NAS workstations (IRIS 1500) at ARC, LaRC, 

and LeRC; (b) Sun workstations at CSU and ARC; (c) NAS Ethernet network and remote 
Ethernets for workstations 

3- Software: software for network communication and network testing 
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4. Laboratory: an LHC Electronics Laboratory for test equipment to monitor 

network performance and measure data transfer characteristics 

5. Facilities: for all above mentioned equipment 

6. Voice coordination: telephones to coordinate the pretests and LHCP experi- 

ments activities 

7. Budget and personnel to perform tests consisting of the following: 

(a) personnel at ARC for the LHCP group; (b) personnel at LaRC and LeRC qualified in 
use of NAS workstations and communications; (c) personnel at CSU qualified in use of 
a Sun workstation and communications 

8. LHCP development plan: the LHCP development plan, which is NAS Projects 

Office reference 1 

Each of the above requirements, except the LHCP development plan, is discussed 
in more detail in the below subsections. 

4.3.2 Communications network requirements.- In order to start these tests at 
the earliest possible time, an interim LHCP network was used. This network had 
full-duplex (FDX) communication lines, at 224 kbps, connecting LaRC and LeRC to the 
NAS Interim Facility (ARC Building N233A). Also, a 56-kbps terrestrial line was 
used to connect CSU to ARC. 

The LHCP network was supplied through Marshall Space Flight Center, which has 
contracted with Boeing to provide the interim circuits until the PSCN circuits that 
Boeing is also developing are available. 

This network included all the necessary equipment (modems, Earth stations, 
etc.) needed to provide data communications paths between ARC and LaRC, LeRC, and 
CSU. 


The LHCP network components at ARC, LaRC, LeRC, and CSU were connected to their 
respective Vitalink VB/1 hardware. 

4.3.2. 1 Communications hardware: The LHCP hardware configurations showing the 

VB/ls, modems, fiber optic systems, and Earth stations (ESs) for ARC, LaRC, LeRC, 
and CSU are shown in figures 2, 3, 4, and 5. 

The communication equipment required at each site and the major components of 
the communications links are discussed in appendix B. 

4. 3. 2. 2 Availability of service: The interim network was to be used until the 

operational PSCN was ready. The PSCN was scheduled to begin operations on 1 April 
1986. Currently, the expected implementation date is July 1986, owing to delays in 
construction of Earth station facilities. 

The scheduled dates for readiness of the interim data communications lines were 
all met. The actual dates on which the lines were ready are enclosed in 
parentheses. 
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Figure 2.- Ames Research Center local LHCP configuration. 


1. 56-kbps terrestrial line between ARC and CSU: 21 June 1985 (actual, 

21 June 1985) 

2. 224-kbps satellite link ready at ARC: 30 August 1985 (actual, 15 August 

1985) 

3. 224-kbps satellite link ready between ARC and LaRC: 16 September 1985 

(actual, 2 September 1985) 

4. 224-kbps satellite link ready between ARC and LeRC: 16 September 1985 

(actual, 16 September 1985) 
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Computer-to-computer communication connections were to follow as soon as possi- 
ble after the communication links were established. The computer-to-computer con- 
nection dates were as follows. 

1. 56-kbps terrestrial connection between ARC and CSU: 2 August 1985; the 

delay was due to slow delivery of DSU equipment by Boeing 

2. 224-kbps satellite connection ready between ARC and LaRC: 10 October 1985; 

RCA required approximately 4 weeks to coordinate the initial ARC/LaRC link 
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Figure 4.- Lewis Research Center local LHCP configuration. 


3. 224-kbps satellite connection ready between ARC and LeRC: 21 October 1985 

4. 3. 2. 3 Performance monitoring: The PSCN service supplying the T1 capability 

provided centralized maintenance control, real-time status, and traffic monitor- 
ing. The ARC site monitored all link performance with the Vitalink Management 
Station (CS/100). Each site could perform monitoring activities on its tail cir- 
cuits, if desired. (Note: During future performance/network testing, each site 

could monitor and record BER, block error rate, impulse noise, etc., with monitoring 
equipment that could be supplied by ARC, such as, the FIREBERD 2000 data error 
analyzer. This monitoring might be required for timely isolation of faults.) 
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Figure 5.- Colorado State University local LHCP configuration. 


4.3.3 Workstation requirements.- The NAS workstation is an IRIS 1500 worksta- 
tion (was upgraded to 2500); manufactured by Silicon Graphics Inc. (SGI), with the 
following features (see NAS Projects Office ref. 3 for a full description). 

1. MC68010 central processor 

2. Multibus 

3. IKON 10077-NSC (NSC HYPERchannel interface adapter) 

4. Interlan Ethernet interface 

5. UNIX System V + 4.1c bsd enhancements 

6. TCP/IP protocol 


19 


NAS/CSU Local Ethernet 





Other workstations, such as the Sun 160 at CSU, that were used in the LHCP 
experiments had capabilities similar to the NAS workstation. 

Initially, the remote NAS workstations located at LaRC and LeRC and the non-NAS 
workstation at CSU accessed a Cray via the gateway host VAX using the LHCP 
network. This provided early user involvement and feedback regarding the develop- 
ment of the LHC subsystem network. 

4.3.4 Software requirements.- The following paragraphs describe the software 
required for the LHCP bandwidth and hardware experiments: 

The NAS workstations and gateway host machines required that TCP/IP, file 
transfer protocol (FTP), and some LHCP developed software be installed before the 
hardware and user bandwidth experiments could be performed. 

All systems ran UNIX (UNIX is a product of AT&T) with TCP/IP and FTP, and were 
compatible with UNIX 4.2 bsd r commands such as rlogin and rep. The IRIS 1500/2500 
ran with SGI's Version 2.1.1 which is equivalent to System V + 4.2 bsd. 

Measurement software for the hardware experiments was developed by the LHCP 
group to test the transfer of data between the remote workstations and the gateway 
host, and to measure the data transfer rates and other characteristics, such as 
number of errors detected during the transfer. The software developed consisted of 
a C program called netpush which did memory-to-memory data transfers. Also, a 
number of UNIX shell scripts were written to automate the testing. Existing soft- 
ware such as the TCP/IP, rep, and rlogin, was incorporated into the systems. These 
high-level test routines that exercised the hardware required that all associated 
system software be installed and operational. Refer to appendix C for a listing of 
the test software netpush. 

Measurement software for the bandwidth experiment, which was designed and 
developed by the LHCP group, consisted of a series of routines and shell scripts. 
These routines automatically recorded the timing for a predetermined sequence of 
steps that a remote user followed while using a workstation. Using these routines, 
different timing measurements were taken. Refer to NAS Projects Office reference 5 
for more details on the test software. 

In order to use the Cray, software was required in the gateway host VAX. This 
software was the Cray station package under UNIX 4.2 bsd (CRINT). Similarly, in 
order to use the NAS Cray-2, a comparable Cray station package such as CXINT and SEP 
was developed. 

4.3.5 NAS LHC prototype laboratory requirements.- The following paragraphs 

will briefly discuss the philosophy of the NAS LHCP laboratory along with the rea- 
sons for the test equipment required for the LHCP experiments. The descriptions of 
each major piece of equipment are given in appendix B. 

Data-line and performance-monitoring equipment were required for the hardware 
tests and for the IOC. This equipment monitored the characteristics and performance 
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of the network to detect and record bit errors, block errors, and noise as a func- 
tion of time. Data-line analyzers and data-monitor sets were required to selec- 
tively monitor and troubleshoot, and to detect speed, protocol, bit-per-character 
value, and parity of the network. 

All test equipment for the LHCP laboratory was provided by the NAS Projects 
Office. Any equipment needed to perform additional testing, if deemed necessary, 
was also provided by the NAS Projects Office. (Note: When the line is leased 

(e.g., the 56-kbps line), some of the test equipment may not be needed because the 
line monitoring will normally be performed by the communications service vendor.) 

To insure reliable low error data transmissions between remote workstations and 
the NAS computers it was important to determine the transmission quality of each 
LHCP link and of the overall LHCP network on a continuing basis. 

An LHCP laboratory was set up to measure and record parameters such as bit 
error rate and data transmission statistics. It was determined that there is a 
correlation between data transmission statistics from the Vitalink bridge boxes and 
parameters such as transport delay. These measurements were made independently of 
the routine maintenance procedures. 

The laboratory also helped locate failures in the NPSN and the communications 
links via network analysis and loopback checks. 

Future laboratory activities will consist of assisting the LHC subsystem devel- 
opment group in testbed activities, and the operations group in problem solving of 
faulty operational LHC links. 

4.3.6 Facilities requirements.- Each site (ARC, LaRC, LeRC, and CSU) was 
responsible for its site preparations. However, the NAS Projects Office provided 
site-preparation guidelines to assist in the installation of the VB/ls. 

Facilities preparation required the installation of the data communications 
network cables, modems, RF equipment, etc., and the identification of the location 
of all demarcation (demarc) points that were established. 

A table of all known demarc points for the LHCP is shown below: 


Site location 

Circuit 

Building 

Room 

ARC 

T1 

N240 

220 

ARC 

224 kbps 

N233A 

097 

ARC 

56 kbps 

N233A 

097 

LaRC 

T 1 

1213 

140 

LaRC 

224 kbps 

1 1 92— E 

129 

LeRC 

T 1 

142 

Parking lot 

LeRC 

224 kbps 

142 

160 

CSU 

56 kbps 

University 

520 


Service Center 
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4.3.7 Voice coordination network requirements.- Telephones were required 

during the hardware experiments, user bandwidth experiments, and TCP/IP tuning tests 
for coordination and to resolve any technical proplems. A standard voice-grade 
telephone line with the telephone located in the area near the LHCP equipment was 
required at ARC, LaRC, LeRC, and CSU. 

The telephones were required during the pretests and during all LHCP experi- 
ments to provide voice communications between the NAS test coordinator; ARC Commun- 
ications Division; Marshall Space Flight Center; LaRC; LeRC; and CSU personnel. 

4.3.8 Personnel requirements.- Each site provided personnel to install, accep- 
tance test, and assist the LHCP group with the prototype experiments. A list of 
responsible personnel from each site is provided in appendix D of reference 1. 

It was envisioned that the NAS Projects Office, in addition to the LHCP mana- 
ger, needed the following NAS Projects Office/ISC personnel to assist in the LHCP: 

1. Data communications engineer or systems engineer 

2. Two systems programmers or software engineers (one full time, one part 

time) 

3. Two technicians 

4. Part-time engineer/technician with current NAS workstation experience 
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APPENDIX A 


AB 

AI 

ARC 

ARPAnet 

ASCII 

AT 

AT&T 

b 

B 

BCS 

BER 

BSC 

BSD 

CBD 

CCF 

CCITT 

CDC 

CFD 

CM 

COS 

CRINT 

CRT 


ABBREVIATIONS 

A box that can switch one input to either of two outputs 

Action item 

Ames Research Center 

Advanced Research Projects Agency Network 

American National Standard Code for Information Interchange 

Acceptance test 

American Telephone & Telegraph 

bit 

byte 

Boeing Computer Services 
Bit error rate 
Bisynchronous 

Berkeley Software Distribution (version of UNIX, which is a trademark of 
Bell Telephone Laboratories) 

Commerce Business Daily 

Central Computer Facility (Ames) 

Consultative Committee for International Telegraphy and Telephone 

Control Data Corporation 

Computational fluid dynamics 

Configuration management 

Cray operating system 

Cray interactive station package for COS 
Cathode ray tube 
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CSP Cray station package 

CSU Channel service unit 

CTO Contract task order 

CXINT Cray interactive station package for UNIX 

DCA Data carrier available 

DCE Data communications equipment 

DEC Digital Equipment Corporation 

DI Device independent 

DSCS Digital satellite communications simulator 

DSU Data service unit 

DTE Data terminal equipment 

EC ARC Computer Systems Division (now RC) 

ECO ARC Computer Systems Division, Operations Branch (now RCO) 

ED ARC Information and Communications Division 

EIA Electrical Institute of America 

ERB Engineering review board 

ES Earth station 

ETI ARC Technical Services Division, Electronic Instrument Services Branch 

FDX Full duplex 

FG Function generator 

FM Frequency modulation 

FTP File transfer protocol 

GE General Electric 

H/W Hardware 
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HDX 

HP 

HQ 

HSP 

I/O 

IBM 

IBM/PC 

ICASE 

ID 

IEEE 

IOC 

IP 

ISC 

ISO 

ISPC 

LAN 

LCD 

LHC 

LHCP 

LHCS 

MB 

MR 

MS-DOS 

MSFC 


Half duplex 
Hewlett-Packard 
NASA Headquarters 
High-speed processor 
Input/output 

International Business Machines Corporation 

International Business Machines Corporation personal computer 

Institute for Computational Applications in Science and Engineering (at 
LaRC) 

Identification 

Institute of Electrical and Electronic Engineers 
Initial operating configuration 
DARPA Internet protocol 

Integration support contractor (General Electric) 

International Standards Organization 
Integrated support processor complex 
Local area network 
Liquid crystal display 
Long-haul communications 
Long-Haul Communications Prototype 
Long-Haul Communications Subsystem 
Megabytes ( 1 , 048,576 bytes) 

Material request (via General Electric) 

Personnel computer operating system 
Marshall Space Flight Center 
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NAS Numerical Aerodynamic Simulation 

NASA National Aeronautics and Space Administration 

NMC Network Message Center 

NPO NAS Projects Office 

NPSN NAS Processing System Network 

NSC Network Systems Corporation 

OBE Overtaken by events 

OEM Original equipment manufacturer 

OPS Operations 

PC Personal computer 

PC-XT IBM personal computer, model XT 

PCCB Program configuration control board 

PG Pulse generator 

PR Purchase request (government) 

PRB Program review board 

PSCN Program support communications network 

RCA RCA Corporation 

RF Radio frequency 

RFP Request for proposal 

RMS AC voltage measurement, root mean squared 

RN Numerical Aerodynamic Simulation (NAS) Projects Office 

RND NAS Systems Development Branch 

RNF NAS Facilities and Operations Branch (now RNS) 

RNS NAS Computational Services Branch 
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S/W Software 

SEP Cray 2 simple effective protocol 

SGI Silicon Graphics Incorporated 

SND NAS Systems Development Branch (now RND) 

SNF NAS Facilities and Operations Branch (now RNS) 

SR Service request (government) 

SSC Systems software contractor (Informatics General) 

STD Standard 

TBD To be determined 

TBS To be supplied 

TCP DARPA transmission control protocol 

TCP/IP ARPAnet transmission control protocol/Internet protocol 

TDMA Time division multiplexing access 

TTC Telecommunications Techniques Corporation 

UNIX Operating System developed by Bell Telephone Laboratories 

UTS Universal Timesharing System (Amdahl) 

VAX Virtual address extension (DEC 32-bit minicomputer) 

VCF Voltage-controlled frequency 

VINOS Vendor- independent NAS operating system 

VMS DEC virtual memory operating system 

WK Workstation 

WKS Workstation subsystem 

WO Washington office 

XNS Xerox network services protocol 
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APPENDIX B 


LHCP COMMUNICATIONS AND TESTING EQUIPMENT 


B . 1 COMMUNICATIONS HARDWARE 

The following paragraphs will discuss the equipment required at each site and 
will describe the major components of the communications links. Refer to Figures 2, 
3, 4, and 5 within section 4.3 for the configurations of each site. The description 
of some of the communication equipment was obtained from the vendor brochures and/or 
operating manuals, when available. 


B.1.1 Vitalink 

Vitalink Communications Corporation provided a product called VB/1 which used 
hardware manufactured by Bridge Communications Inc. and a software package called 
TransLAN developed by Vitalink to interface with Ethernet. The model number for 
this hardware is Communications Server/ 1 or CS/1, but is referred to as VB/1. Each 
remote site did have one VB/1. The ARC site did have two VB/ls to communicate with 
LaRC, LeRC and CSU. In addition to the two VB/ls at ARC, a Network Management 
Station or Communications Server/100 (CS/100) was connected to the NAS Ethernet at 
ARC to allow monitoring of the remote VB/ls. 

The CS/100 serves as an interface between individual devices and an Ethernet 
network by establishing virtual circuit connections between these devices. The 
CS/100 supports most terminals, printers, personal computers, host computers, 
modems, word processors and other devices with serial interfaces. Complete networks 
of non-Ethernet devices can be implemented by connecting all elements to the network 
through the CS/1 and CS/100. 

The CS/100 has the following features and capabilities: 

(1) CS/100-BSC (Bisynchronous) supports character synchronous communications 
through an RS232 interface on all ports. 

(2) CS/100 can include both host and user interfaces. 

(3) CS/100 is a master controller that can control or look at any of the CS/1 
Bridges configurations located at the remote locations. 

The CS/1 with the TransLAN software is a hardware and software system designed 
to connect any number of Ethernet or IEEE-802.3 Local Area Networks (LANs) so they 
appear as one large "Local Area Network". 

The CS/1 has the following features and capabilities: 

(1) The bridge and communications software interconnects LANs with digital 
transmission systems. TransLAN may thus interconnect LANs via public communications 
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networks (telephone lines) or through private or public satellite or microwave 
systems. 

(2) The VB/1 Bridge stores and forwards entire LAN frames and automatically 
"learns" which are local and which are remote. The VB/1 Bridge, therefore, is able 
to filter and discard messages addressed to local stations, keeping local traffic on 
one LAN from congesting the interconnect media or the remote LANs. Filtering allows 
bridges to use substantially lower link speed than those used on the LAN. 

(3) Each VB/1 Bridge can support up to eight V.35/RS232 satellite channels/ 
terrestrial ports. Port card capacity is 224kbps. 

(4) TransLAN can be used to expand networks indefinitely in a modular fashion 
by linking VB/1 Bridges together. 

The LHCP group is responsible for all Vitalink equipment supplied to the sites. 

A short description of the Vitalink company and cost information for the 
Vitalink equipment used in the LHCP is discussed in NPO reference 1, appendixes B 
and C. 


B.1.2 Fibercom IFL-70 

The Fibercom IFL-70 analog fiber optic system is used to convert a 70 MHz 
signal to a fiber optic signal and vice versa. The IFL-70 devices allowed data from 
the satellite Earth station to be transmitted to the COMTECH SM200A modems which 
interface with the Vitalink VB/ls via a V.35 interface. 

Code ED is responsible for the Fibercom IFL-70s located at ARC. RCA is respon- 
sible for those installed at LaRC and LeRC. 


B.1.3 COMTECH SM200A 

The COMTECH SM200A converted the 70 MHz signal from the IFL-70 to be compatible 
with V.35 so that the signal can be transmitted to the Vitalink VB/ls. The COMTECH 
SM200As installed at ARC, LaRC and LeRC have the (dual) redundant feature. This 
feature provided for backup in case the primary channel interface board fails. 

RCA is responsible for the COMTECH SM200AS installed at ARC, LaRC and LeRC. 


B.1.4 Fiber Optic Cable 

At ARC, fiber optic cables are being strung between the IFL-70s to connect the 
Earth station at Bldg. N240 Room 220 with the VB/ls at Bldg. N233A Room 097. Fiber 
optic cables also were used at LaRC and LeRC to connect their Earth stations to 
VB/ls. The fiber optic cables did meet or exceed the specifications of Belden 
Series 227400 fiber optic cable. 


29 



Code ED is responsible for the fiber optic cables at ARC. Each site was 
responsible for the fiber optic cables that were strung. 


B.1.5 CSU/DSU 

A Channel Service Unit/Data Service Unit (CSU/DSU) is used to connect the VB/1 
to the 56kbps terrestrial line at ARC. Another CSU/DSU is used at Colorado State 
University to tie their VB/1 to the other end of the 56kbps line. A CSU/DSU is 
essentially a high-speed modem. The CSU/DSU units at ARC and CSU are supplied and 
were maintained by Boeing under the PSCN effort. 


B.1.6 Earth Station 

For the satellite links, Earth stations (ES) with up and down converters are 
used to send and receive data via satellite networks. Satellite links and/or Earth 
stations were provided by RCA at ARC, LaRC and LeRC. These services are being 
supplied under the PSCN contract by Boeing/RCA. 

At ARC and LaRC, existing RCA/NASA Earth stations were used. A RCA transport- 
able Earth station was provided at LeRC. The interface will be V.35 on a Winchester 
34 pin connector. RCA provided the clocking for the signals. 

RCA is responsible for all services delivered to the Earth stations at each 

site. 


B.2 LHCP ELECTRONIC LABORATORY TESTING EQUIPMENT 


The following paragraphs present a description of each major piece of testing 
equipment required by the LHCP Electronics Laboratory. The description of some of 
the test equipment was obtained from the vendor brochures and/or operating manuals, 
when available. 


B.2.1 Digital Satellite Communications Simulator 

The Digital Satellite Communications Simulator (DSCS) is a microprocessor-based 
system designed to simulate the time delay, error conditions and electrical inter- 
faces which characterize a full duplex digital satellite circuit. The DSCS consists 
of two distinct units: the model 1010B Satellite Digital Delay Simulator and the 

1020B Satellite Digital Error Simulator. The DSCS is made by Telecommunications 
Techniques Corporation (TTC). 

The 1010B Satellite Digital Delay Simulator is used to create a delay satellite 
circuit environment in the lab. The 101 OB has the following features and 
capabilities : 
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(1) Capable of introducing up to 999 milliseconds of delay to both data paths 
of a full duplex (FDX) channel allowing simulation of a single or multiple hop 
satellite transmission path. 

(2) Capable of interfacing with data terminal equipment (DTE) through RS232, 
RS449, V.35 and DS1 (T1). 

(3) Capable of varying bit rates from 2400 bps to 6.312 Mbps. 

(4) Capable of being remotely controlled through IEEE-488 interface. 

The 1010B works by having the delay controller store data in the delay memory 
until the programmed delay time has expired. The delay memory then sends the data 
out as received data. 

The 1010B Satellite Digital Delay Simulator is designed to operate either as a 
standalone instrument or in conjunction with the 1020B Satellite Digital Error 
Simulator. 

The 1020B Satellite Digital Error Simulator is used to create an error satel- 
lite circuit environment in the lab. The 1020B has the following features and 
capabilities: 

(1) Capable of introducing Gaussian distributed bit errors, with or without 
burst characteristics, over a wide range of bit error rates to both data paths of a 
FDX channel allowing realistic simulation of a satellite channel error 
characteristics. 

(2) Capable of interfacing with data terminal equipment (DTE) through RS232, 
RS449, V.35 and DS1 (T1). 

(3) Capable of varying bit rates from 2400 bps to 6.312 Mbps. 

(4) Capable of being remotely controlled through IEEE-488 interface. 

The 1020B is composed of two parts, the error controller and the error genera- 
tor. The error controller is programmed by the processor to the specific error rate 
selected. The error controller then sets the error generator to this error rate and 
sends the data through the error generator circuitry where the errors are introduced 
into the data. 

The 1020B can be used to develop and test virtually any type of terminal equip- 
ment and supporting software prior to using expensive satellite facilities. 

The 1020B Satellite Digital Error Simulator is also designed to operate either 
as a standalone instrument or in conjunction with the 1010B Satellite Digital Delay 
Simulator. 
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B.2.2 Data Error Analyzer 


The Data Error Analyzer is a microprocessor-based system designed to measure 
bit error rates, errors, seconds of testing, errored seconds, blocks, and block 
errors simultaneously. The Data Error Analyzer performs bit and block error mea- 
surements under local or remote control for testing the quality of data communica- 
tions circuits. 

Three FIREBERD 2000 Data Error Analyzers manufactured by Telecommunications 
Techniques Corporation (TTC) were procured for use at ARC, LaRC and LeRC. The 
FIREBERD 2000 was used to support the LHCP experiments and is essential for the 
detection and measurement of bit and block errors during the transmission of data 
via the VB/ls and communications lines. 


B.2.3 Electronic Counter 

The Hewlett-Packard HP Model 5335A is a Universal Counter capable of measuring 
signals in the 200 MHz range. The instrument's basic measurement functions include 
frequency, period, time, ratio, and totalize. The resident microprocessor and 
multiple-register-counter expand the usefulness of the counter by allowing post- 
measurement data manipulation. This allows the additional power and convenience of 
user-defined measurement function keys for statistical data, math functions, pulse 
width, rise/fall time, slew rate, duty cycle, and phase relationships. Interpolat- 
ing oscillators, phase-locked to the instrument's time base, allow measurements to 
be resolved near a nanosecond. 

The 5335A input provides two independent channels, featuring matched high 
performance 200 MHz input amplifiers. Each input channel includes a full complement 
of signal conditioning controls. Additionally, the 5335A offers extensive control 
of triggering and arming. Most measurements are displayed in scientific notation, 
with the digits grouped into three's for convenience. Four modes of gate selection 
are provided on the front panel. 


B.2.4 Ethernet Analyzer 

The LANalyzer EX 5000E Ethernet Network Analyzer is a sophisticated yet easy- 
to-use tool for developing, debugging, and characterizing LAN; for monitoring net- 
work traffic and measuring network performance; and for testing, troubleshooting, 
and maintaining LANs. The LANalyzer EX 5000E is designed for operation on Ethernet 
(Versions 1.0 and 2.0) and IEEE 802.3 compliant LANs. All LANalyzer functions are 
realized by running tests. Test results can be viewed immediately on completion of 
a test, or stored to an MS-DOS file for later examination and analysis. 

The LANalyzer is a product of EXCELAN. The LANalyzer hardware and software are 
available in a kit form that easily installs and operates on an IBM PC XT, IBM PC 
AT, or compatible. The LANalyzer system is also available pre-installed (and 
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tested) in a COMPAQ PORTABLE 286, which is ideal for applications requiring 
portability . 

The LANalyzer has the following features: 

(1) Monitors/captures up to 1000 packets/second on sustained basis, indepen- 
dent of protocol 

(2) Captures packets according to user-defined criteria and start/stop 
triggers 

(3) Accurately time-stamps captured packets 

(4) Displays statistics graphically in real time 

(5) Generates controlled amounts of traffic 


B.2.5 Logic Analyzer 

The Hewlett-Packard 1630A/D is a general purpose logic analyzer for use in the 
design, debug, and functional test of digital hardware and microprocessor hardware 
and software. It features measurement capability in two domains of interest to the 
digital system designer: state and timing. Functionality in either of these two 
domains is available to the user separately or in interactive combination. 

The 1630 is a stand alone, benchtop instrument with intergal keyboard and 
display, but it may be remotely programmed by an external controller over its built 
in HP-IB (Hewlett-Packard Interface Bus). HP-IB also provides linkage to the 
peripherals such as a number of disks and printers. A micro floppy disk can be 
connected to the 1630 for the store and recall of measurement configurations and 
acquired data. A printer will provide hardcopy of waveforms, listings, and instru- 
ment configurations at the touch of a key. 


B.2.6 RS232 Interface Analyzer 

The Electro Standards Laboratory, Inc. Model 700 EIA RS-232 Interface Analyzer 
is a diagnostic tool designed for use at the standard EIA RS-232 or CCITT V.24 data 
interface of modems, multiplexers, terminals, and computers. It is simply inserted 
in series between the data terminal equipment (DTE) and the data communications 
equipment (DCE) to provide access to and monitoring of all data, timing, and control 
signals. 

The unit is of optimum design utilizing state of the art tri-state light emit- 
ting diodes to clearly display polarity, activity, and validity of all interface 
signals. Miniature rocker switches allow the user to program a 'make' or 'break' 
for each signal at the DCE/DTE interface. Mini-patchcords are provided for cross- 
patching or loopback patching of signals at the front panel test point array. 
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A complete table of EIA/CCITT standard interface signal description is provided 
inside the unit for ready reference during testing. A covered compartment provides 
secure storage for mini-patchcords and an El A ribbon cable. The unit is battery 
powered for complete portability, pocket-sized for convenience and packaged in a 
sturdy aluminum case for durability in field service use. 


B.2.7 Signal Generator 

FG 504 Function Generator - The TEKTRONIX FG 504 Function Generator provides low 
distortion sine, square, triangle, ramp, and pulse waveforms over the frequencies 
from 0.001 Hz to 40 Hz in 10 decades. A user-definable custom frequency range is 
also available. The output amplitude is 10 mV to 30 V peak-to-peak into an open 
circuit and 5 mV to 15 V peak-to-peak into a 50-ohm load. The output impedance is 
50 ohms. The FG 504 may be swept between the START and STOP FREQ dial settings with 
a linear or logarithmic sweep. The output may be phase locked, gated, or triggered 
for single cycle output. The output waveform may be shifted + or - 80 degrees from 
the triggering waveform. The symmetry of the output waveform may also be varied. 

For the slower frequencies, the output may be held at any level by pushing the f.ont 
panel button labeled HOLD. 

A voltage-controlled frequency (VCF) input controls the output frequency from 
an external voltage source. The output frequency can be swept above or below the 
selected frequency, to a maximum of 1000:1, depending on the polarity and amplitude 
of the VCF input and the selected output frequency. Provision is also made for 
amplitude modulating the sine wave output from an external source. 

The variety of swept and modulated signals available from the FG 504 make it 
especially useful for such applications as testing amplifier or servo-system 
response, distortion, and stability. It is useful for FM generation, as a beat 
frequency oscillator, as a gated triggered or phase-locked logic interface, or as a 
source for various ramp or pulse waveforms. It is also useful as a source for 
amplitude modulated signals for various purposes. 

PG 502 Pulse Generator - The TEKTRONIX PG 502 is a 250 MHz general purpose pulse 
generator usable in the TM 500-series power modules only. Major capabilities of the 
instrument include high repetition rate, narrow pulse width, fast rise-time, and 
independent pulse top and bottom level controls. Front-panel controls provide 
manual trigger, square-wave output, complementary pulse output for high duty 
factors, and selectable back termination in the pulse output circuitry. All other 
inputs and outputs are internally terminated at 50 ohms. Triggers preceding the 
output pulse are available at the front panel. The pulse output may also be exter- 
nally triggered. 

The front panel is color coded for easy reference to controls and their associ- 
ated functions. Orange denotes pulse duration controls and settings; green, trig- 
gering functions; and the frequency equivalents for the pulse period settings are 
listed in red. 
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B.2.8 Standard Bus (STD BUS) 


The Standard Bus was not procured by the LHCP group since no time was available 
to fully explore its possible uses. However, the LHCP group does recommend that the 
LHCS group investigate the functionality of the STD BUS and perhaps procure it for 
use in future development activities. 

The Standard Bus (STD BUS) with the IBM PC-XT is a digital/analog developmental 
system. It allows many different functioning circuit boards to be configured 
together into a working system under microcomputer control. Depending on the type 
of cards and software installed, it can be used to control tests, and to collect, 
process, and plot data for systems such as the NAS LHCS. 

The main component of the system is the 702A Standard Bus Chassis. It contains 
a 13-slot card cage, 2 floppy disk drives (8 inch), fan and power supply. The 
system can be set up and programmed to gather, plot, store and process data from the 
Vitalink VB/1 bridge box, the Network Management Station, the Satellite Delay Simu- 
lator and the Bit Error Rate Test Set. 

The IBM PC-XT will be used for system control, software development, and data 
and program storage. By connecting the STD BUS System to an IBM PC-XT via an inter- 
face board and software, applications programs can be written in languages such as 
Pascal, Assembly or Fortran. The programs are compiled by the IBM PC-XT and then 
downloaded to the STD BUS system. 

Examples of uses are: 

(1) Receive and integrate data from Ethernet Analyzer, Bit Error Rate Test 
Set, and Vitalink VB/1 bridges to determine the correlation between Ethernet packet 
load activity, Ethernet retransmissions and packet errors and traffic density, 
retransmissions in the VB/1 bridge and bit error rate. 

(2) Run a Fourier Analysis of digital data coming from a remote site to con- 
vert from the time domain to the frequency domain looking for noise frequency compo- 
nents that will help locate problems in the transmission links. 

(3) The STD BUS/IBM PC-XT system will automatically control the collection of 
data 24 hours a day and generate reports periodically. This system will be accessi- 
ble to NAS Operations when the LHCP experiments are concluded. 

Data can be sent to the STD BUS several different ways: IEEE 488 - Bit Error 

Rate Test Test; RS232 - Vitalink VB/1 Bridges; parallel digital - Ethernet Analyzer. 


B.2.9 Multimeter 

The Hewlett-Packard 3468A/B is a fully programmable HP-IL (Hewlett-Packard 
Interface Loop) digital multimeter. HP-IL is a serial interface allowing the HP 
Model 41C/CV family of calculators or desktop computers such as the HP Model 85 to 
control your 3468A/B. In an automatic test or on the bench, the 3468A/B offers 
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3 1/2 to 5 1/2 digit resolution for measuring do volts, true rms ac volts, 2- and 
4-wire ohms, and dc and rms ac current. The 3468A/B offers dc voltage performance 
from 1 yV sensitivity up to 300 V (full scale), true rms ac voltage capability up to 
300 kHz, and resistance measurements from 1 m£2 sensitivity to 300 Mft (full scale). 
Its dc and true rms ac current measuring capability is from 10 yA sensitivity up to 
3 A. The optional battery pack provides up to 5 hours of continuous portable 
operation. 

By selecting the number of digits displayed and using the autozero feature, the 
3468A/B allows you flexibility in measurement speed and accuracy. Up to 31 readings 
per second can be made with the 3468A/B in the 3 1/2 digit mode. The fast autorange 
feature of the 3468A/B allows fast bench measurements over a wide dynamic range. 

The alphanumeric liquid crystal display (LCD) gives you measurement units as 
part of the reading for easy-to-read, unambiguous answers. The HP-IL talk, listen, 
remote, and SRQ status information is also available with the LCD annunciators. The 
SRQ button can be used to flag or interrupt your calculator from the front panel of 
the 3468A/B. 

The 3468A/B is calibrated electronically, either manually from the front panel 
or remotely in an automatic calibration system. There are no internal adjustments 
and the calibration of all functions is done without the removal of covers. The 
self-test function verifies most of the internal circuitry of the 3468A/B indicating 
proper operation of the multimeter. 


B.2.10 Lab Oscilloscope 

The TEKTRONIX 7603 Oscilloscope is a solid state, lightweight instrument 
designed for general-purpose measuring applications. This instrument has three 
plug-in compartments that accept TEKTRONIX 7-series plug-in units to form a complete 
measurement system. The two plug-in compartments on the left are connected to the 
vertical deflection system. The right plug-in compartment is connected to the 
horizontal deflection system. Electronic switching between the vertical plug-in 
compartments allows a multi-trace vertical display. The flexibility of this plug-in 
feature and the variety of plug-in units available allow the system to be used for 
many measurement applications. In addition, the instrument contains a readout 
system to provide a CRT display of alphanumeric information from the plug-in 
units. Data such as deflection factor and sweep rate can be encoded and displayed 
on the CRT. 

The instrument features a large-screen, 8 X 10 division display; each division 
equals 1.22 centimeters. The CRT provides small spot size and fast writing speed. 
Regulated dc power supplies ensure that performance is not affected by variations in 
line voltage and frequency, or by changes in the load due to the varying power 
requirements of the plug-in units. Maximum power consumption is about 170 W (60 Hz, 
115-V line). 
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APPENDIX C 


LHCP EXPERIMENTS 


LHCP Hardware Experiments 1, 2, and 3 
Test Results 

By Bohden K. Cmaylo and Trevor Eisenman 
May 1, 1986 

This report describes the results of the LHCP network performance tests (H/W 
tests) run between various components and/or hosts on the LHCP network. Section C.1 
contains the report of the H/W tests. 


Impact of TCP Send/Receive Window Size on Network Performance 
Test Results - Second Test Date 
By Jonathan Hahn 
March 17, 1986 

This report describes the results of some follow-up network performance tests 
run between Amelia and ICASE, two VAX 11/780 computers networked together over a 
satellite communications link. Section C.2 contains the report of the TCP/IP tests. 


LHCP TCP/IP and XNS Comparisons 
Test Results 
By Bohden K. Cmaylo 
23 September 1986 

This report describes the results of the LHCP network testings run between two 
identical IRISs on the LHCP network using either the rep program, which uses the 
TCP/IP protocol, or the xcp program, which uses the XNS protocol. These tests were 
performed at the request of the NAS Workstation Subsystem Manager, Tom Lasinski. 
Section C.3 contains the report of the TCP/IP-XNS tests. 


Long Haul Communications Prototype Experiments Results 

Test Results 
By Judy McWilliams 
TBD 

The User Bandwidth experiment evaluated the use of remote communications links 
between IRIS 1500/2500 and Sun 160 WKs and the NPSN resources to determine remote 
user bandwidth requirements. The report on the User Bandwidth experiment will be 
found in NP0 reference 8. 
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C.1 LHCP HARDWARE EXPERIMENTS 


This report describes the results of the LHCP network performance tests (H/W 
tests) run between various components and/or hosts on the LHCP network. The compo- 
nents included: Ethernet, Vital ink VB/ls, Satellite Delay Simulator, and computers 
such as VAX 11/780, Sun 160, IRIS 1500 & 2500. Each computer had a UNIX type oper- 
ating system and had a TCP/IP protocol implementation for remote communication. 
These tests were performed from April 1985 through April 1986. 


C.1.1 Scope 

The scope of these H/W tests was to exercise all portions of the LHCP net- 
work. Possible problems, such as poor performance, could be isolated to a specific 
portion of either the hardware or software by varying these parameters for each 
test. An other reason for performing these tests included LHCP familiarization with 
every portion of the LHCP network. In order to obtain a "feel" of the LHCP network, 
it was necessary to exercise the network over and over. 


C.1. 2 Tests Performed 

The key to each entry for the "Hardware Test Matrices" is defined in the below 
Figure C.1. 2-1. The entries within each TEST MATRIX of figure C.1. 2-2 indicate what 
data were collected over a simulated communication link. Unfortunately only H/W 
tests 1, 2, and 3 were completed. H/W tests 4 and 5 will be completed (and/or 
revised) at a later date by the LHCS group. 

LHCP HARDWARE TEST NOTES 


VAX A VAX 11/780 running BSD 4.2 system 

IRISo An IRIS 1500 (Excelan model 101 Ethernet board) running UNIX System 5 
IRISn An IRIS 2500 (Excelan model 201 Ethernet board) running UNIX System 5 
Sun A Sun model 160 running BSD 4.2 UNIX 
UTS An Amdahl 5840 running UTS 5 


Y Collected data for this entry 

y Collected data for this entry, but they are not needed 

N No data collected for this entry, but wanted data 

n Do not want data collected for this entry 

M Collected some data for this entry, but need more data 

m Collected some data for this entry, but they are not needed 

5 Used as a suffix for the above notes indicate 56kbps test results also 

r Used as a suffix for the above notes indicate using a real link only 


Figure C.1. 2-1 LHCP Hardware Test Notes. 
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Figure C. 1.2-2 Hardware Test Matrices. 
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C.1.3 Testing Conditions 

The following five conditions were needed to be satisfied in order to run the 
H/W tests. 

(1) Segments of an experimenter's time of at least two hours were required for 
each test point. Usually more time was required for each test point because of 
difficulties that would arise during the test, such as losing the link. 

(2) The availability of computer accesses on two different computer systems. 
Whenever a workstation was used, standalone time was requested because other users 
on the workstation would degrade the data transmission rate. Whenever a mainframe, 
such as a VAX, was used, the tests were performed during a low usage period so that 
the loading on the computer would not have a great effect on the data transmission 
rate. 


(3) A dedicated (or an unloaded) communication link between the two com- 
puters. This usually required that the Vitalink equipment be dedicated for the 
tests, therefore the remote users would not be able to communicate with the NAS 
system. 

(4) Both computers had to communicate with each other via the communication 
link. TCP/IP was selected since this was the protocol of choice for the NAS. 
Unfortunately this protocol was not always in use on the workstations at ARC, espe- 
cially since the initial workstation to the Cray X-MP/12 connection was through a 
VMS VAX running an XNS protocol. Therefore, dedicated time was required on the IRIS 
workstation to switch the XNS kernel to a TCP/IP kernel. 

(5) Software was needed to perform the data transmissions and to report on the 
transmission rates. 

Netpush(local) was developed for the LHCP group to perform memory-to-memory 
transmissions of varying buffer sizes using the TCP/IP protocol. Test shell scripts 
were also developed to use netpush over various parameters. See Sections C.1.22, 
C.1.23, C. 1 .24, C. 1 .25, and C.1.26 for listings of shell scripts and program 
listings. 


C.1.4 Test H/W Configurations 

There were five types of H/W tests planned. They were: 

(1) An Ethernet Baseline test. This test was to get initial data so that 
future tests could be analyzed against this baseline. Figure C. 1.4-1 is an example 
of the computers and communication link needed for performing H/W test 1. 

(2) A Vitalink Baseline test. This test was to see how the Vitalink equipment 
performed compared to the previous test. Figure C. 1.4-2 is an example of the com- 
puters and communication links needed for performing H/W test 2. 
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(3) A modified Vitalink test using transport delays. This was to introduce 
delays in the data communication by placing a satellite delay simulator into the 
circuit. Figure C. 1.4-3 is an example of the computers and communication links 
needed for performing H/W test 3. 

(4) A bit error rate baseline test. This was to repeat H/W Test 2 except that 
various levels of bit error rates were to be introduced into the circuit. Figure 

C. 1.4-4 is an example of the computers and communication link needed for performing 
H/W test 4. 

(5) A bit error rate with transport delay test. This was to repeat H/W Test 3 
except that various levels of bit error rates were to be introduced into the cir- 
cuit. Figure C. 1.4-5 is an example of the computers and communication link needed 
for performing H/W test 5. 
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LHCP Hardware Test 1 


Terminator 


□ 



A 


Terminator 

Purpose: Determine data transmission characteristics between two 
computers connected via Ethernet. (Ethernet Baseline Test) 

Data transfers (memory to memory) from 8 bytes to 1 megabyte, 
increasing sizes by power of two. 

Figure C. 1.4-1 H/W Test 1 - Ethernet Baseline Configuration 
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LHCP Hardware Test 2 



CD 


Terminator 

Purpose: Determine data transmission characteristics via Vitalink boxes 
between two computers on different Ethernets. (Vitalink Baseline Test) 
Data transfers (memory to memory) from 8 bytes to 1 megabyte, 
increasing sizes by power of two. 

Figure C. 1.4-2 H/W Test 2 - Vitalink Baseline Configuration 
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LHCP Hardware Test 3 
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Purpose: Determine data transmission characteristics via Vitalink 
boxes, given transport delays of .01 and .25 seconds, between two 
computers on different Ethernets. (Terrestrial and Satellite simulation) 
Data transfers (memory to memory) from 8 bytes to 1 megabyte, 
increasing sizes by power of two. 

Figure C. 1.4-3 H/W Test 3 - Transport Delay Configuration 
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LHCP Hardware Test A 
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Purpose: Determine data transmission characteristics via Vitalink 
boxes, given selected bit error rates, between two computers on 
different Ethernets. (Bit Error Rate Baseline Test) 

Data transfers (memory to memory) from 8 bytes to 1 megabyte, 
increasing sizes by power of two. 

Figure C. 1.4-4 H/W Test 4 - Bit Error Rate Baseline Configuration 
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LHCP Hardware Test 5 
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Purpose: Determine data transmission characteristics via Vitalink 
boxes, given transport delays of .01 and .25 seconds and selected bit 
error rates, between two computers on different Ethernets. 

Data transfers (memory to memory) from 8 bytes to 1 megabyte, 
increasing sizes by power of two. 

Figure C. 1.4-5 H/W Test 5 - Bit Error Rate with Transport Delay Configuration 
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C.1.5 Raw H/W Test Data 


Figure C. 1.5-1, on the following page, describes the definitions of the head- 
ings of the following tables of "raw data" collected. The headings are a brief 
description of the computers used, the type of simulated communication medium, the 
transport delay, and a suffix "r" for when a real link was used. The format of the 
header column is: Field1-Field2/Field3/Field4. An example "raw data" table follows: 

BUFFER (size in bytes) Field1-Field2/Field3-Field4 . . . 


BYTES 


DATA (in 1000 bytes per second) 


C.1.6 Analysis of Selected Tests 

Various combinations of logical comparisons were selected to observe how the 
data transmission rates varied. The comparisons generally followed five guidelines: 

(1) If a measurement was taken in one direction, that is machine A transfer- 
ring data to machine B, then the reverse direction was also measured. 

(2) Identical systems were compared at different link transmission rates. 

(3) Identical systems were compared with different transport delay rates. 

(4) Different systems were compared using identical conditions. 

(5) Peak rates were selected to minimize loading effects. 

Graphs follow the below guidelines: 

(1) X-axis is in terms of bytes in a netpush buffer transmission, that is, one 
request of the program to transfer that many bytes. Multiple requests were always 
used so that the total time per program execution was between 10 to 30 seconds. 

(2) Y-axis is in terms of kilobytes per second. 

(3) The legend titles follow the same format as in the raw H/W data tables. 
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Axis 

— i mss i 1 i a t s caae ass —see 

Description 

Y-axis 

The "Buffer" identifies the "Y" axis of each table which consists of the 
number of bytes given to netpush for a memory to memory transmission 

X-axis 

The "X" Axis Heading Identifies a single type of test configuration 

"CELL" 

Each entry within the table not identified by the heading "Buffer" is in 
units of "Kilobytes (1000) per second" transmission rate. 

COMPUTER 

Fieldl and Field2 - Description of Computers 

la 

IRIS 2500 workstation at ARC called "annie" with a 201 Ethernet board 

ILa 

IRIS 1500 workstation at LaRC called "larc" with a 101 Ethernet board 

ELe 

IRIS 1500 workstation at LeRC called "lerc" with a 101 Ethernet board 

Io 

IRIS 1500 workstation at ARC called "igor" with a 101 Ethernet board 

Iw 

IRIS 2500 workstation at ARC called "wks" with a 201 Ethernet board 

11 

IRIS 1500 workstation at ARC called "wkOl" with a 101 Ethernet board 

14 

IRIS 1500 workstation at ARC called "wk04" with a 101 Ethernet board 

Ss 

Sun 160 workstation at CSU called "surya" 

Sw 

Sun 150 workstation at ARC called "wiley" 

UTS 

Amdahl 5840 at ARC called "prandtl" 

Va 

VAX 11/780 at ARC called "amelia" 

VLa 

VAX 11/780 at LaRC called "icase" 

LINK 

Field3 - Link Description 

mem 

Indicates internal computer memory to memory transfers only. 

E 

10 Megabits per second Ethernet 

2 

224 Kilobits per second communication link 

5 

56 Kilobits per second communication link 

TRANSPORT 

Field4 - Transport Delay 

0 

No delay introduced 

1 

.01 second transport delay introduced (Terrestrial line) 

2 

.25 second transport delay introduced (Satellite line) 


Figure C. 1.5-1 Definition of Raw H/W Test Data Matrices. 
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Buffer 

Va-Va/mem 

Va-Sw/E/0 

Va-Iw/E/0 

Va-Io/E/0 

Ia-Va/E/0 

Iw-Va/E/0 

8 

0.8 

2.4 





16 

2 

4.5 





32 

4 

5.9 





64 

7.5 

11.8 





125 

6.4 

24.2 

11.6 

10.4 

13.4 

12.5 

250 

19.1 

33.7 

39.1 

13.9 

22.1 

22.1 

500 

11.3 

33.2 

32.9 

20 

34.9 

31.3 

1000 

40.1 

39.2 

50 

27 

54.5 

68.2 

2000 

63 

57.1 

54.9 

26.7 

10.2 

62.5 

4000 

85.3 

62.3 

61.7 

27.7 

28.9 

26.5 

8000 

72.6 

59 

67.6 

29.9 

18.6 

19.3 

16000 

33.2 

57.5 

74.8 

33.1 

16 

16.1 

32000 

88.4 

64.6 

75 

34.2 

16.3 

15.6 

64000 

115.5 

63.1 

75.3 

35 

15.8 

19.2 

128000 

113.7 

76.8 

72.2 

35.4 

15.3 

15.7 

256000 

122.5 

75.2 

73.1 

35 

15.3 

15.4 

512000 

125.4 

77.2 

72.6 

34.1 

15.4 

15.7 

1024000 

72.1 

76.8 

66.3 

29.1 

15.4 

15.4 

8 

0.5 

1.9 





16 

1.1 

4.2 





32 

2 

7.8 





64 

4.7 

9.1 





125 

13.5 

23.9 

26 

10.1 


12.5 

250 

26.9 

38.2 

39.1 

16.9 


20.8 

500 

43.3 

53.4 

48.1 

22.7 


32.6 

1000 

52.1 

66 

55.6 

29.2 


75 

2000 

80.7 

63.8 

57.5 

26.3 


69.8 

4000 

84.9 

62.9 

59.5 

28.9 


33.7 

8000 

83.9 

65.1 

64.4 

30.5 


17.8 

16000 

78.4 

67.3 

67.4 

34 


16.1 

32000 

59 

69.4 

69.1 

34.8 


15.6 

64000 

65.2 

79.2 

67.8 

34.9 


15.7 

128000 

82.5 

78 


35.6 


16.6 

256000 

84.4 

77 


33.8 


15.6 

512000 

75.3 

79.6 


32.7 


15.4 

1024000 

56.9 

71.5 


26.3 


15.5 


Figure C. 1.5-2 Table 1 - H/W Tests Raw Data. 



Buffer 

(cont) 

Va-Va/mem 

(cont) 

Va-Sw/E/0 Va-Iw/E/0 
(cont) (cont) 

Va-lo/E/0 

(cont) 

Ia-Va/E/0 

(cont) 

Iw-Va/E/0 

(cont) 

10 

0.4 

2.5 

2.5 

1.5 

1.5 

100 

20 

25 

11.1 

15 

15 

1000 

52.6 

62.5 

21.7 

75 

75 

10000 

94.3 

64.9 

34.8 

20.8 

21 

100000 

117.6 

66.6 

37.1 

15.6 

15.6 

1000000 

130.9 

66.2 




10 

0.8 

2.5 

3.33 

0.9 

1.5 

100 

7.1 

25 

25 

12 

12 

1000 

37 

62.5 

28.6 

54.5 

54.5 

10000 

75.2 

65.4 

36 

18.1 

19.5 

100000 

86.9 

66.4 

37.4 

15.5 

15.5 

1000000 

86 

64.9 

38.3 



10 

1 



1.5 


100 

16.7 



8.6 


1000 

66.7 



75 


10000 

90.1 



17.2 


100000 

121.4 



15.7 


1000000 

124.5 





10 

0.6 



1.3 


100 

10 



12.5 


1000 

41.7 



69 


10000 

93.5 



18.8 


100000 

104 





1000000 

121.4 






Figure C. 

1.5-3 Table 1 (cont) 

- H/W Tests 

Raw Data 
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Buffer 

Va - VLa / 2 / 2 r 

Va - Iw / 2/0 

8 

2.1 

0.263 

16 

2.7 

0.557 

32 

2.8 

1.081 

64 

2.8 

3.582 

125 

4.3 

9.92 

250 

3.2 

8.823 

500 

2.9 

12.305 

1000 

3.1 

10.589 

2000 

3.1 

15.24 

4000 

3 

15.645 

8000 

3 

16.096 

16000 

3.1 

15.655 

32000 

2.9 

15.576 

64000 

3.1 

14.712 

128000 

3 

14.275 

256000 


14.341 

512000 


14.063 

8 

1.8 

0.409 

16 

2.6 

0.887 

32 

2.5 

2.182 

64 

2.8 

3.263 

125 

3.6 

9.469 

250 

3 

8.055 

500 

3 

10.33 

1000 

3.2 

12.755 

2000 

3 

15.616 

4000 

3 

15.81 

8000 

3.2 

15.296 

16000 

3 

15.946 

32000 

3 

16.279 

64000 

3.1 

15.533 

128000 


15.616 

256000 


15.323 

512000 


15.867 


■ILa/2/2r 

Va-ILe/2/2r 

VLa-Iw/2/2r 

0.364 

0.723 

0.96 

6.656 

0.629 

2.043 

0.592 

0.712 

2.551 

1.147 

0.883 

2.601 

2.34 

1.798 

2.847 

3.015 

2.606 

2.844 

2.714 

2.787 

2.724 

2.675 

2.842 

2.677 

2.614 

2.66 

2.662 

2.663 

2.663 

2.793 

2.69 

3.022 

2.713 

2.735 

2.707 

2.679 

2.687 

2.672 

2.675 

2.747 

2.597 

2.825 

2.622 

2.704 

2.592 

2.567 

2.562 

2.571 

2.565 

2.547 

2.531 

0.481 

0.682 

1.324 

0.641 

0.629 

1.646 

0.668 

0.574 

2.49 

1.206 

0.678 

2.341 

2.345 

2.306 

2.676 

2.662 

2.429 

2.815 

2.552 

2.785 

2.741 

2.677 

2.674 

2.696 

2.645 

2.692 

2.797 

2.888 

2.762 

2.734 

2.695 

2.687 

2.712 

2.699 

2.75 

2.755 

2.666 

2.669 

2.673 

2.606 

2.682 

2.619 

2.577 

2.592 

2.531 

2.652 


2.583 

2.55 


2.689 


Figure C. 1.5-4 Table 2 - H/W Tests Raw Data. 
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Buffer size 

Ia-UTS/2/0 

Ia-UTS/2/2 

Ia-Sw/2/0 

Iw-Ia/E/0 

Iw-Ia/2/0 

10 

1.4 

1.7 

1.2 

0.9 

14.6 

100 

12.5 

4.5 

6 

8.6 

12.7 

1000 

13 

3.3 

23.1 

60 

23.2 

10000 

10.2 

2.4 

12.4 

57.1 

11.8 

100000 



11.8 

42 


10 

1.4 

1 

1.2 

0.9 

14.3 

100 

14 

3 

12 

15 

13 

1000 

13.5 

2.9 

28.6 

54.5 

23.3 

10000 

10.7 

2.3 

12.8 

61.2 

12.4 

100000 



11.4 

20.8 



Figure C. 1.5-5 Table 3 - H/W Tests Raw Data. 


Buffer 

Iw-Ia/2/2 

Sw-Ia/2/2 

UTS-Ia/2/0 

Sw-Ia/2/0 

10 

1.5 

3.3 

4.3 

5 

100 

10.9 

25 

5 

25 

1000 

6.5 

3.3 

14.6 

17.9 

10000 

3.8 

3.1 

15.2 

19.2 

100000 




18 

10 

1.1 

3.3 

1.3 

2.5 

100 

5.9 

25 

10.4 

25 

1000 

5.4 

3.3 

8 

20 

10000 

3.6 

2.9 

13.6 

18.7 

100000 




16.1 

10 

1.4 




100 

5.9 




1000 

5.1 




10000 

3.5 





Figure C. 1.5-6 Table 4 - H/W Tests Raw Data. 
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Buffer 

(cont) 

VLa-Sw/2/2r 

(cont) 

Ia-Iw/E/0 

(cont) 

Iw-Va/2/0 

(cont) 

Sw-VLa/2/2r 

(cont) 

Sw-Va/E/0 

(cont) 

Iw-Ia/5/2 

(cont) 

8 

0.23 


0.889 

1.78 

2.6 


16 

0.312 



2.497 

4.4 


32 

0.601 



2.419 

7 


64 

1.965 


8.888 

2.87 

15.5 


125 

2.388 

6.8 

13.975 

3.038 

25.2 


250 

2.327 

25 

22.5 

2.945 

39.1 


500 

2.784 

42.9 

20.547 

2.72 

50 


1000 

2.976 

60 

15.873 

3.007 

61.7 


2000 

2.979 

30 

19.533 

2.964 

53.2 


4000 

3.075 

50 

7.947 

3.039 

57.5 


8000 

3.029 

55.8 

14.53 

2.994 

58.1 


16000 

2.933 

26.9 

12.834 

2.939 

59.8 


32000 

3.039 

20.2 

12.723 

3.008 

56.5 


64000 

3.076 

36.3 

13.12 

3.06 

65 


128000 

3.074 


13.264 

3.082 

64 


256000 

3.086 


12.962 

3.109 

60.1 


512000 

3.107 


13.079 

3.069 

64.7 


1024000 





48.4 


8 

0.65 



2.325 



16 

0.795 



2.539 



32 

1.679 



2.687 



64 

2.3 



2.816 



125 

2.27 

12.5 


2.911 



250 

2.267 

20.8 


2.925 



500 

2.394 

28.8 


2.739 



1000 

2.196 

71.4 


2.987 



2000 

2.171 

75 


2.972 



4000 

2.208 

50 


3.004 



8000 

2.191 

65.2 


2.976 



16000 

2.145 

33.8 


2.986 



32000 

2.161 

17.8 


2.969 



64000 

2.174 

27.9 


3.079 



128000 

2.158 

16.4 


3.037 



256000 

2.141 



3.068 



512000 

2.166 



3.036 




Figure C. 1.5-8 Table 5 (cont) - H/W Tests Raw Data 
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Buffer 

Va-Sw/2/0 

Sw-Sw/mem 

Sw-Va/2/0 

I1-I4/2/1 

I1-I4/2/2 

Iw-VLa/2/2r 

8 

0.94 

1.3 

2.373 



1.185 

16 

2.488 

2.5 

5.031 



2.307 

32 

6.852 

4.9 

8.02 



3.282 

64 

3.374 

9.6 

12.524 



3.002 

125 

9.96 

14.9 

17.361 

6 

6.3 

3.588 

250 

8.96 

25 

18.796 

10.3 

1.3 

3.456 

500 

14.144 

37.3 

20.661 

15.4 

3.8 

3.257 

1000 

15.037 

48.2 

21.834 

24.5 

5.9 

2.746 

2000 

18.298 

67.8 

21.436 

23.5 

5.6 

2.733 

4000 

18.957 

64.3 

21.621 

14.7 

3.8 

3.157 

8000 

19.138 

69 

21.563 

9.8 

3.3 

2.9 

16000 

18.369 

73.7 

21.447 

9.6 

2.9 

2.703 

32000 

18.642 

88.2 

20.539 

8.8 

3.3 

2.62 

64000 

15.311 

91.4 

21.333 

7.7 

2.9 

2.683 

128000 

14.198 

100 

21.955 

8.2 

2.8 

2.783 

256000 

16.176 

97.4 

22.397 

8.8 


2.618 

512000 

16.778 

100.1 

19.976 



2.61 

1024000 


79.7 





8 

1.258 

1.3 

2.484 



1.185 

16 

2.651 

2.6 

4.678 



2.347 

32 

8.779 

4.9 

8.184 



3.327 

64 

9.026 

9.6 

12.307 



3 

125 

17.123 

14.8 

17.123 

5.8 

5.7 

3.571 

250 

18.382 

25.7 

18.656 

9.4 

6.3 

2.581 

500 

19.723 

37.3 

20.746 

14.6 

3.9 

3.218 

1000 

20.02 

47.8 

21.276 

23.8 

5.4 

2.908 

2000 

20.253 

67.9 

20.408 

23.2 

5.3 

2.734 

4000 

20.997 

63.5 

21.857 

11 

5 

3.217 

8000 

21.534 

70.8 

20.565 

10.3 

3.3 

2.952 

16000 

21.066 

71.9 

20.942 

9.1 

2.9 

2.746 

32000 

20.853 

85.1 

21.476 

8.4 

3.7 

2.57 

64000 

21.658 

96.7 

20.447 

8 

3 

2.861 

128000 

21.639 

98.2 

18.823 

7.5 

2.9 

2.846 

256000 

21.557 

100.3 

17.889 

8.1 


2.645 

512000 

21.165 

101.1 

21.368 



2.636 

1024000 


79.9 






Figure C. 1.5-9 Table 6 - H/W Tests Raw Data. 
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Buffer 

Sw-UTS/E/0 

Ss-Va/5/lr 

Io-Va/E/0 

I1-I4/E/0 

I1-I4/2/0 

8 

1.2 

0.8 




16 

1.9 

1.4 




32 

0.7 

2.5 




64 

0.8 

3.7 




125 

19.5 

4 

5.4 

5.9 

5.9 

250 

16.4 

5.4 

9.1 

12.5 

9.8 

500 

39.7 

5.9 

13.6 

14.9 

14.8 

1000 

42 

6.1 

28.8 

33.3 

23.8 

2000 

26.4 

6.1 

29.4 

33.9 

23.4 

4000 

12.7 

5.6 

29.9 

33.6 

12 

8000 

37.4 

6.1 

29.8 

32.3 

8.3 

16000 

32.4 

6.1 

19.3 

32.5 

8 

32000 

30.4 

5.9 

21.9 

17.5 

8 

64000 

20.8 

6.2 

23.8 

27.2 

7.7 

128000 

18.7 

6.1 

18.1 

25.8 

7.7 

256000 

29.4 

6.1 

18.4 


7.7 

512000 

39.4 

5.8 

17.8 


7.7 

1024000 

34.9 

6.1 

20 


7.6 

8 


0.9 




16 


1.5 




32 


2.7 




64 


3.7 




125 


5.2 

5.6 

6.3 

6.3 

250 


5.5 

9 

12.5 

10.3 

500 


6 

14.4 

15 

15.8 

1000 


6.2 

28.8 

33 

25 

2000 


6.2 

29.4 

33.9 

23.8 

4000 


6.3 

24.3 

33.4 

13.9 

8000 


6.1 

28 

32.5 

11.9 

16000 


6.2 

15.8 

32.4 

7.9 

32000 


6.1 

17.1 

19.6 

8 

64000 


5.6 

24.2 

12.9 

7.8 

128000 


5.5 

26.7 

12.6 

7.7 

256000 


6.2 

25.3 


7.7 

512000 


5.5 

22.6 


8.6 

1024000 


6 

23.8 


7.7 


Figure C. 1.5-10 Table 7 - H/W Tests Raw Data. 
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Buffer 

(cont) 

Sw-UTS/E/0 Ss-Va/5/lr Io-Va/E/0 

(cont) (cont) (cont) 

I1-I4/E/0 

(cont) 

I1-I4/2/0 

(cont) 

10 

3.1 

1.3 

0.6 

0.6 

0.6 

100 

1 

12.5 

5 

5.5 

5.7 

1000 

42.3 

7.2 

26.1 

33.1 

25 

10000 

38.9 

6.2 

29.6 

32.9 

9.7 

100000 


6.1 

28.5 

31.3 

8.3 

1000000 




23.3 


10 

2.9 

1.7 

0.5 

0.6 

0.6 

100 

22.7 

16.7 

4.3 

5.6 

5.5 

1000 

22.7 

7.2 

27.3 

33.1 

23.6 

10000 

28.4 

6 

29.3 

33 

10 

100000 


6.1 

29.1 

33.2 


1000000 




23.7 


10 


1.9 

0.5 

0.7 


100 


5.2 

4 

6 


1000 


6.2 

26.1 

35.3 


10000 


6.1 

26.9 

29 


100000 



28.2 

29.1 


1000000 




29.1 


10 


1.7 


0.6 


100 


5.6 


5 


1000 


6.2 


33.3 


10000 


6.1 


28 


100000 




17.4 


1000000 




25.5 



Figure C. 1.5-11 Table 7 (cont) 


H/W Tests Raw Data. 
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Buffer 

Va-Sw/2/2 

Sw-Va/2/2 

Sw-Va/5/0 

Va-Sw/5/0 

Va-Sw/5/2 

Sw-Va/5/2 

8 

1.418 

2.352 

0.931 

0.599 

0.66 

0.7 

16 

1.946 

2.768 

1.153 

0.921 

0.753 

0.823 

32 

2.379 

2.792 

1.993 

1.466 

1.471 

1.691 

64 

2.605 

2.839 

2.557 

1.76 

1.604 

2.044 

125 

2.99 

3.125 

3.453 

3.156 

1.733 

2.055 

250 

3.008 

2.906 

3.72 

3.227 

2.004 

2.039 

500 

2.881 

2.84 

3.897 

3.668 

1.992 

1.963 

1000 

3.016 

2.826 

4.078 

3.827 

1.985 

1.981 

2000 

3.028 

3.036 

4.089 

3.711 

1.922 

1.845 

4000 

3.115 

3.169 

4.219 

3.892 

1.853 

2.049 

8000 

2.967 

3.062 

4.217 

3.8 

1.931 

1.89 

16000 

2.905 

2.852 

4.138 

3.818 

1.982 

1.914 

32000 

3.095 

3.081 

4.115 

3.701 

1.945 

1.935 

64000 

2.983 

2.922 

4.188 

3.842 

2.014 

2.068 

128000 

3.114 

3.021 

4.373 

3.726 

2.012 

2.014 

256000 

3.096 

3.085 

4.061 

3.795 

1.885 

1.932 

512000 

3.111 

3.092 

4.168 

3.77 

1.904 

1.915 

8 

1.818 

2.424 

0.94 

0.507 

0.246 

0.701 

16 

2.247 

2.209 

1.141 

0.521 

0.808 

0.77 

32 

2.668 

2.807 

1.986 

1.314 

1.364 

1.807 

64 

2.622 

2.799 

2.63 

2.41 

1.801 

2.02 

125 

3.18 

3.078 

3.633 

3.246 

1.902 

1.959 

250 

2.955 

3.012 

3.787 

3.676 

2.012 


500 

2.705 

2.512 

4.152 

3.762 

1.984 


1000 

3.08 

3.113 

4.159 

2.787 

1.929 


2000 

3.033 

2.983 

41.62 

3.627 

1.927 

1.923 

4000 

3.041 

2.998 

4.192 

3.78 

2.046 

1.879 

8000 

3.001 

3.041 

4.203 

3.825 

1.961 

1.927 

16000 

3.012 

2.888 

4.186 

3.623 

1.876 

1.902 

32000 

3.1 

3.056 

4.172 

3.525 

1.912 

1.909 

64000 

3.135 

2.993 

4.199 

3.678 

2.021 

1.98 

128000 

2.958 

2.957 

4.189 

3.621 

2.025 

1.92 

256000 

3.07 

3.028 

4.165 

3.411 

1.905 

1.921 

512000 

3.054 

2.992 

4.18 

3.682 

1.971 

1.94 


Figure C. 1.5-12 Table 8 - H/W Tests Raw Data. 
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Buffer 

Va-Iw/5/0 

Iw-Va/5/0 

Iw-Va/5/2 

Va-Iw/5/2 

ILa-Va/2/2r 

ILe-Va/2/2r 

8 

1.333 

1.243 

1.118 

0.701 

0.5 

0.5 

16 

1.273 

2.227 

1.594 

0.803 

0.9 

0.9 

32 

1.817 

4.314 

2.15 

1.441 

1.9 

1.8 

64 

2.386 

4.643 

2.107 

1.743 

3.1 

2.7 

125 

3.396 

5.597 

2.373 

1.987 

3.4 

3.4 

250 

3.09 

5.208 

2.173 

2.122 

• 3.1 

3.2 

500 

3.443 

4.854 

2.094 

2.115 

3.1 

3.1 

1000 

3.481 

4.669 

2.104 

2.098 

2.5 

2.6 

2000 

3.773 

4.643 

2.062 

2.094 

2.2 

2.2 

4000 

4.166 

4.678 

2.065 

2.065 

3.1 

3.2 

8000 

3.992 

4.473 

2.05 

2.055 

2.4 

2.5 

16000 

3.924 

4.473 

1.89 

2.048 

2.5 

2.4 

32000 

3.766 

4.44 

1.823 

2.045 

2.1 

2.1 

64000 

4.081 

4.604 

1.972 

2.022 

2.9 

2.7 

128000 

3.808 

4.457 

1.714 

2.023 

2.4 

2.7 

256000 

3.894 

4.391 

1.938 

2.048 

2.2 

2.3 

512000 

3.851 

4.366 

2.006 

1.983 

2.3 


1024000 





2.1 



Figure C. 


.5-13 Table 9 - H/W Tests Raw Data. 
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C.1.7 IRIS(IOI) to IRIS(IOI) via 10Mbps and 224kbps, no delay 

This was the first comparison test for the IRIS using the old Ethernet 101 
board. This test noted the difference of transmission rate due to the communication 
link. The analysis reveals that the 10Mb Ethernet link displayed the maximum trans- 
mission rate, as expected, while the 224kbps link showed degradation of transmission 
speed due to link loading. Fall-off of transmission rates also occurred at higher 
buffer sizes for netpush, which was assumed to be a buffer fragmentation effect. 
Figure C. 1.7-1 presents the graph of the results. 


Memory-Memory from IRIS(IOI) to IRIS(IOI) over Ethernet end 224kbps with no deley 

II -14 /E /O/p ‘°* 11-14 /2 /O/p * Maximum 224kbps 



Figure C. 1.7-1 IRIS(IOI) to IRIS(IOI) via 10Mbps and 224kbps, no delay. 
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C.1.8 IRIS(201) to IRIS(201) via 10Mbps and 224kbps, no delay 

This was the first comparison test for the IRIS using the newer Ethernet 201 
board. This test noted the difference of transmission rate due to the communication 
link. Again, as expected, the analysis revealed that the 10Mb link displayed the 
maximum transmission rate, while the 224kbps link showed degradation of transmission 
speed due to link loading. Fall-off of transmission rates also occurred at higher 
buffer sizes for netpush. Figure C. 1.8-1 presents the graph of the results. 


Memory-Memory |RIS(201) to IRIS(20t) via 10Mbps and 224Kbps with no delay 

Is-hr/E/O/p -O' lv-la/2/O/p * Maximum 224kbps 



Figure C. 1.8-1 IRIS(201) to IRIS(201) via 10Mbps and 224kbps, no delay. 
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C.1.9 IRIS(IOI) to IRIS(IOI) & IRIS(201 ) to IRIS(201) via 10Mbps, no delay 

This was a comparison test for the IRIS using the old and new Ethernet boards 
over the 10Mbps Ethernet link. This test noted the difference of transmission rate 
due to the Ethernet boards. The analysis revealed that the new board displayed at 
least double the transmission rate of the old board, except at 32000 buffer size 
where an unknown dip in rates occured, and over 128000 buffer sizes where the fall- 
off of transmission rates occured for the new 201 board. The old 101 board did not 
exhibit the fall-off due to larger buffers. Figure C. 1.9-1 presents the graph of 
the results. 


Memory-Memory IRI5C20 1 ) to IRIS(20I) & IRIS(IOI) to IRIS(IOI) via 10Mbps with no deloy 

la-lv/E/O/p ,0 * 11-14/E/O/p 



Buffer Size (Bytes) 

Figure C. 1.9-1 IRIS(IOI) to IRIS( 101 & IRIS(201) to IRIS(201) via 10Mbps, no 

delay . 
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C.1.10 IRIS(IOI) to IRIS(IOI) & IRIS(201 ) to IRIS(201) via 224kbps, no delay 

This was a comparison test for the IRIS using the old and new Ethernet boards 
over the 224kbps link. This test noted the difference of transmission rate due to 
the Ethernet boards. The analysis revealed that while the 224kbps link degraded 
both sets of tests, the new board displayed higher transmission rates than the old 
board at low buffer sizes (less than 1000 bytes), but showed a similar maximum rate 
as the old board. Figure C. 1.10-1 presents the graph of the results. 


Memory-nemory IRIS(20I) to IRIS(20t) and IRlS(IOt) to IRIS(IOI) via 224Kbps. no delay 


*•* hr-U/2/0/j 11-14/2/0/p ■' Maximum 224kbps 



10 100 1000 10000 100000 1000000 

Buffer Sizf (Bytes) 


Figure C. 1.10-1 IRIS(IOI) to IRIS(IOI) & IRIS(201) to IRIS(201) via 224kbps, no 

delay. 
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c.1.11 IRIS(IOI) to IRIS(IOI) via 224kbps with 0, .01, and .25 delay 

This was a comparison test for the IRIS using the old Ethernet 101 board over 
a local 224kbps link, a long (2000 mile) simulated 224kbps terrestrial link, and a 
224kbps satellite link. It noted the difference of transmission rate due to the 
type of communication link. The analysis revealed that the local and long terres- 
trial link showed almost identical rates, while the satellite link was greatly 
affected by the .25 second each way transport delay. A large ( ~60% ) drop-off of 
transmission rates occurred for buffer sizes greater than 2000 bytes. This was 
attributed to buffer fragmentation. Figure C. 1.1 1-1 presents the graph of the 
results . 


Memory-Memory from IRIS(IOI) to IRIS(tOt) over 224kbps with 0, .01, .25 delay 


lt-M/2/0/p II -M/2/1 /p * ll-M/2/2/p Huirn 224kbps 



Figure C. 1.1 1-1 IRIS(IOI) to IRIS(IOI) via 224kbps with 0, .01, and .25 delay. 
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C.1.12 VAX to/from IRIS(IOI) and IRIS(201) via 10Mbps, no delay 

This was a comparison test which paired two different types of computers, a VAX 
11/780 going to either an IRIS with a new or old type Ethernet board. It noted the 
change of transmission rate due to the effect of the VAX computer speed on the 
different IRIS Ethernet boards. The analysis revealed that while the VAX was trans- 
ferring data to the IRIS (both 101 and 201 boards), the transmission rates generally 
increased with the increase of buffer sizes, and the IRIS(201) was generally twice 
as fast as the IRIS(IOI). However, when the IRIS(201) transferred data to the VAX, 
the transmission rate suffered a “75% drop in speed at buffer sizes greater than 
2000 bytes, while the IRIS(IOI) only dropped “30?. These drops made the IRIS(201) 
perform “25? worse than the IRIS(IOI) board at buffer sizes over 4000 bytes. Figure 
C. 1.1 2-1 presents the graph of the results. 


nemory-Memory from VAX to/from IRIS(IOI) and IRIS(201) over Ethernet with no delay 

Va-lw/E/O/p ■©* tv-Va/E/O/p '•* Va-la/E/O/p 

Q la-Va/ESO/p Maximum 224kbps 



Buffer Sira (Bptas) 


Figure C. 1.12-1 VAX to/from IRIS(IOI) and IRIS(201) via 10Mbps, no delay. 
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C.1.13 VAX to/from IRIS(201) via 224kbps and 10Mbps, no delay 

This was a comparison test for a VAX and I RIS( 20 1 ) over two types of communi- 
cation links. It noted the difference of transmission rate due to the type of com- 
munication link. The analysis revealed that the 10Mb link displayed the maximum 
transmission rate, while the 224kbps link showed degradation of transmission speed 
due to link loading. It also showed that the IRIS(201) to VAX transmission drop 
produced a similar end rate as the end rate for the 224kbps communication link. 
Figure C. 1.1 3-1 presents the graph of the results. 


Memory-Memory from VAX to/from IRIS(20I) over Ethernet end 224ICbps with no deley 


V»- Iv/E /O/p -O* tv-V«/E/0/p * V«-hr/2/0/p 

•O lv-V*/2/0/p MaxtMM 224kbps 



10 100 1000 10000 100000 1000000 

Bvfftr Stz* CBjtfrs) 

Figure C. 1.13-1 VAX to/from IRIS( 20 1 ) via 224kbps and 10Mbps, no delay. 
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ORIGINAL FAQS is 
QE POOR QUALITY 

C.1.14 VAX to/from IRIS(201) via 224kbps and 56kbps, no delay 

\ 

This comparison test for the VAX to IRIS(201) noted the difference over a 
medium and low speed communication link. The analysis revealed that the 224kbps 
link displayed the higher transmission rate as expected, but the rate was not con- 
stantly higher in one direction. The 56kbps was limited to link loading, but the 
transmission speed was constantly higher in the IRIS(201) to VAX transmission direc- 
tion. Figure C. 1.1 4-1 presents the graph of the results. 


flemory-Hemory from VAX to/from IRIS(201) over 224Kbps end 56Kbps with no delay 

Va-hr/2/O/p lv-Va/2/0/p *■* V<-tW9/0/p 

o lv-Va/5/0/p *- Maximum 224kbps ■*- Maximum 96kbps 



Figure C. 1.14-1 VAX to/from IRIS(201) via 224kbps and 56kbps, no delay. 
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C.1.15 VAX to/from IRIS(201) via 56kbps with and without .25 delay 

This was a comparison on a lower rate communication link with an introduced 
satellite delay. The results indicated that the satellite delay accounted for 
approximately 50 % of the communication. Figure C. 1.15-1 presents the graph of the 
results. 


Memory-Memory from VAX to/from IRIS(201) over 56Kbps with 0 and .25 second delay 

Va-lw/5/0/p "O' hr-Va/5/O/f ♦ V«-hr/3/2/» ° hr-Va/S/2/r ** MaxtowMi 36 »m 



10 100 1000 10000 100000 1000000 

avffar Six* (Bytes) 

Figure C. 1.15-1 VAX to/from IRIS(201) via 56kbps with and without .25 delay. 
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OF POOR QUALITY 

C.1.16 VAX to/from IRIS(201) via 224kbps with and without .25 delay 

This was a comparison on a higher rate communication link with an introduced 
satellite delay. The results indicated that the satellite delay accounted for 
approximately 90% of the communication. The rest, 1 0% , was the effective transmis- 
sion rate. Also indicated was the fact that the TCP/IP protocol was not tuned for 
the satellite delay. See section C.2 for more information on TCP/IP tuning. Fig- 
ure C. 1.16-1 presents the graph of the results. 


tlemory-Memory from VAX to/from IRIS(20l) over 224Kbps with 0 end .25 second delay 

*♦* V«-lv/2/0/» *0' tv-Va/2/O/p '■* Vl«-lW2/2r/» 


•O lv-VU/2/2r/» HaxtaMMi 224kfcps 



10 100 1000 10000 100000 1000000 

Bvfftr Sic* (Oft**) 

Figure C. 1.16-1 VAX to/from IRIS(201) via 224kbps with and without .25 delay. 
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C.1.17 VAX to/from Sun via 224kbps and 10Mbps, no delay 

This was a comparison test for a VAX and a Sun over two types of communication 
links. It noted the difference of transmission rate due to the type of communica- 
tion link. The analysis revealed that the 10Mb link displayed the maximum transmis- 
sion rate, while the 224kbps link showed degradation of transmission speed due to 
link loading. It also showed that the Sun to VAX transfer did not drop on the end 
rate as did the end rate for the I RIS( 201 ) to VAX in Figure C. 1.13-1. Note that 
the Sun/VAX rates appear faster over all buffer sizes and communication link types 
than the IRIS( 201 )/VAX rates. Figure C. 1.17-1 presents the graph of the results. 


Memory-Memory VAX to SUN via 10Mbps and 224Kbps, no delay 

•♦* Va-Sv/E/O/p *<>' 8w-V*/E/0/p V«-Sv/2/0/p 


0 Sv-Va/2/0/p Maxima* 224kfcps 



Buffer Sin (Bytas) 


Figure C. 1.17-1 VAX to/from Sun via 224kbps and 10Mbps, no delay. 
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C.1.18 VAX to/from Sun via 224kbps and 56kbps, no delay 

This comparison test for the VAX to Sun noted the difference over a medium and 
low speed communication link. The analysis revealed that the 224kbps link displayed 
the higher transmission rate as expected and was limited to link loading. The 
56kbps was also limited to link loading. Note that the VAX/Sun 224kbps rates appear 
faster and smoother than the VAX/IRIS(201 ) rates in the similar Figure C. 1.14-1. 
Figure C. 1.18-1 presents the graph of the results. 


Memory-Memory VAX to SUN via 224Kbps and 56Kbps, no delay 

V«-Sw/2/0/» "O' Sv-Va/2/O/p '■* V«-Sv/5/0/p 

-O Sv-Vi/5/0/p HixtoMM 224kfcps ^ Maximum 56 kbps 



Bvfftr Sin (Byt#s) 


Figure C. 1.18-1 VAX to/from Sun via 224kbps and 56kbps, no delay. 
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C.1.19 VAX to/from Sun via 56kbps with and without .25 delay 

This was a comparison on a lower rate communication link with an introduced 
satellite delay. The results indicated that the satellite delay accounted for 
approximately 50 % of the communication. The results from Figure C. 1.15-1 indicate 
similar results for this test, except for the IRIS(201) to VAX rate, which was 
almost twice the rate at buffer sizes under 1000 bytes to slightly higher (+10£) 
over 1000 bytes. Figure C. 1.19-1 presents the graph of the results. 


nemory-Hemory VAX to SUN via 56Kbps. with and without .25 dalay 

Va-Sv/5/O/p Sv-V«/3/0/p V*-Sv/3/2/p D 8«-V«/5/2/p Hu<M* 36fc*px 



0 1 — - | — — " I- 1 I ... — 1 

10 100 1000 10000 100000 1000000 

ftrfftr Sin (Bytes) 


Figure C. 1.19-1 VAX to/from Sun via 56kbps with and without .25 delay. 
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C.1.20 VAX to/from Sun via 224kbps and 56kbps with a .25 delay 

This was a comparison on a medium and low rate communication link with an 
introduced .25 second satellite delay. The 224kbps was ~1000 bytes per second 
faster than the 56kbps link over all buffer sizes. This result indicated that the 
satellite delay accounted for approximately 50J of the communication for the low 
rate, and up to 90% for the medium rate. This result is similar to the one 
described in both Figure C. 1.15-1 and Figure C. 1.16-1. Figure C. 1.20-1 presents the 
graph of the results. 


nemory-nemory VAX to SUN via 224Kbps and 56Kbps. with .25 delay 

V«-SW2/2/p ^ Sv-Va/2/2/p * Va-Sv/S/2/p ° Sv-Va/S/2 tp 



10 100 1000 10000 100000 1000000 

Bafftr 8te* 


Figure C. 1.20-1 VAX to/from Sun via 224kbps and 56kbps with a .25 delay. 
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C. 1 .21 IRIS(IOI) & IRIS(201 ) to VAX via real 224kbps with .25 delay 

This comparison shows the differences between the IRIS(IOI) and IRIS(201) 
transferring to a VAX over a real 224kbps satellite link. The results show that 
all the transmission rates were almost identical in their slowness. This result 
compares favorably with the previous simulated result in Figure C. 1.20-1. Fig- 
ure C. 1.21-1 presents the graph of the results. 


Memory-Memory from IRISOOI end 201) to VAX over 224Kbps with .25 second delay 


-*■ lv-VL*/2/2r7p “O' IL*-V«/2/2r/p 


IL*-Va/2/2r/p 


4.0 T 

3.5 
3 0 

2.3 

2.0 

1.3 



Bvfffcr Sic* (By t*s) 


Figure C. 1.21-1 IRIS(IOI) & IRIS(201) to VAX via real 224kbps with .25 delay. 
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C.1.22 H/W Test Shell Scripts 


TEST - Shell Script for controlling shell script TEST2 


# control for test2 over all testing 

# params: $1 = to host, $2 = 1st digit buffers, $3 = socket # 
echo test $* 

set num=$2 

if ($2 == "") set num=l 

set sock=$3 

ruptime 

test2 $18 2 ${num}000 4 $sock 
ruptime 

test2 $1 125 2 ${num}00 5 $sock 
ruptime 

test2 $1 4000 2 ${num}0 4 $sock 
ruptime 

test2 $1 64000 2 $num 4 $sock 
ruptime 
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TESTl - Shell Script for controlling "netpush* 


# h/w testing ... to $1 starting at $2 adding $3 buffers $4 and $5 passes 
echo :::: Start of test 1 on ‘date' :::: 
echo : 

echo testl $* 

echo ‘hostname* to $1, bytes $2, adding $3, buffers $4, passes $5 
echo : 

@ cnt = 0 
@ buff = $2 
loop: 

@ cnt = $cnt + 1 
echo : 

echo ::: pass Sent ::: 

echo : 

date 

netpush -v $1 Sbuff $4 
@ buff = Sbuff + $3 
if ( Sent < $5 ) goto loop 
echo : 

echo :::::: completed test 1 ::::: 
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TEST2 - Shell Script for controlling program "netpush" 


# h/w testing .. to $1 starting at $2, times $3 each pass, $4 buffers 

# $5 passes, socket $6 
echo : 

echo :::: Start of test 2 on ‘date' :::: 
echo : 

echo test2 $* 

echo ‘hostname* to $1, start bytes $2, times $3/pass, buffers $4, passes $5 
if ($6 != " ") echo -- socket number $6 -- 
@ cnt = 0 
@ buff = $2 
loop: 

@ cnt = Sent + 1 
echo : 

echo ::: pass Sent ::: 

echo : 

date 

netpush -v $1 Sbuflf S4 $6 
@ buff = Sbuff * $3 
if ( Sent < $5 ) goto loop 
echo : 

echo :::::: completed test 2 ::::: 
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C. 1 .23 Netpush.c Program Listing for a VAX running BSD 4.2 Unix 


/* 

* 

* NOTE: THIS SOURCE CODE WILL ONLY RUN ON A 4.2BSD VAX. 

* 

* Author: Steve Wall 

* Modified: Bohden K. Cmaylo 

* 

* netpush.c 

* 

* Synopsis: netpush [-v] host buffersize ^blocks #port 

* 

★ 

* "Netpush" is used to test transfer rates across the network using a stream 

* socket. We are attempting to do memory to memory transfers to measure 

* raw throughput rates, but of course the TCP protocol will cause some 

* overhead. 

* 

* We allow for different sized buffers to be transferred to account for 

* any discrepancies that may occur between small bulk transfers and large 

* bulk transfers. I really don’t know if the size of the buffer transferred 

* affects the performance of the network subsystem. 

* 

7 

^include <sys/types.h> 

#include <sys/socket.h> 

#include <sys/time.h> 

^include <netinet/in.h> 

^include <netdb.h> 

^include <stdio.h> 

#include "netpush.h" 

main(argc, argv) 
char *argv[]; 

{ 

int sock; /* our socket */ 

char *buffer; /* our buffer */ 

double fend, /* floating pt. representation of ending time */ 

fstart; /* " " " " starting " */ 

long x, /* scratch variable */ 
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portnumber, /* variable port input number */ 

bufsize, /* size of buffers that we will transfer */ 
nbufs; /* number of buffers we will transfer */ 

struct timeval start, /* start time */ 

end; /* end time */ 

struct sockaddr_in server; /* address of remote host */ 
struct hostent *host, /* host information */ 

*gethostbyname(); 


r 

* Verbose mode? 

V 

if (strcmp(argv[ 1] , B -v " ) == 0) { 
verbose = 1; 

++argv; —argc; 

} 

/* 

* Check for command line arguments. 

V 

if (argc == 5) 

portnumber=atoi(argv[4]); 

if (argc < 4 | argc > 5) 
usageQ; 


/* 

* If buffersize is too long, default to MAXBUFSIZE as defined 

* in netpush.h 

7 

if ((bufsize = atoi(argv[2])) > MAXBUFSIZE) { 

printf(" Buffer size requested too large; using %d ".MAXBUFSIZE); 
printf("byte buffers.(newline)"); 
bufsize = MAXBUFSIZE; 

} 

nbufs = atoi(argv[3]); 

gethostname(hostname, (int) sizeof(hostname)); 

/* 

* Set up the socket. 

7 

if ((sock = socket(AF_INET, SOCK.STREAM, 0)) < 0) { 
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perror("netpush: Couldn’t open stream socket"); 
exit(l); 

} 

if ((host sss gethostbyname(argv[l])) == NULL) { 

fprintf(stderr," Unknown host: %s(newline)",argv[l]); 
exit(l); 

} 

server. sin_family = AF_INET; 

bcopy(host->h_addr, &(server.sin_addr.s_addr), host->h_length); 
if (argc == 4) 

server.sin_port = htons(PORTNUMBER); 
if (argc == 5) 

server .sin_port = htons(portnumber); 
if (verbose) { 

printf(" (socket# %d)(newline)",htons(server.sin_port)); 

} 

if (connect(sock, &server, sizeof(server)) < 0) { 
close(sock); 

perror("netpush: Couldn’t connect stream socket"); 
exit(l); 

} 

/* 

* Get the buffer space needed. 

V 

if ((buffer = (char *) malloc((unsigned) bufsize)) == NULL) { 
close(sock); 

fprintf(stderr," Couldn’t get enough memory for buffer. (newline)"); 
exit(l); 

} 

if (verbose) { 

printf("%s: Transferring %ld buffers of %ld bytes each 

hostname, nbufs,bufsize); 

printf(" Total bytes: %ld(newline)", (long) nbufs * bufsize); 

} 

/* 

* Get starting time. 
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7 

gettimeofday(&start, (struct timezone *) NULL); 

r 

* Send a header to the remote machine informing it of the total 

* number of bytes to expect. 

7 

x = nbufs * bufsize; 
sprintf (szbuf , " %ld " ,x); 
write(sock, szbuf, sizeof(szbuf)); 

r 

* Transfer the buffers. 

7 

x = nbufs; 
while (x— ) { 

if (write(sock, bufFer, bufsize) < 0) { 

perror("netpush: Trouble writing to socket"); 

close(sock); 

break; 

} 

} 

/* 

* Get ending time. 

7 

gettimeof day (&end, (struct timezone *) NULL); 
if (verbose) { 

printf("%s: Waiting for verification of successful transfer.(newline)", 

hostname); 

} 

/* 

* Wait for verification from remote host. 

*/ 

read(sock, szbuf, sizeof(szbuf)); 

x = atol(szbuf); 

if (x != nbufs * bufsize) { 

printf("(Bell)Transfer botched - Sent: %d Recv: %d(newline)", 

nbufs * bufsize, x); 

exit(l); 


81 



} 

if (verbose) 

printf("%s: Received verification. (newline)", hostname); 

/* 

* Print out timing information. 

7 

fend = end.tv_sec + (end.tv_usec / 1000000.0); 
fstart = start.tv_sec + (start.tv_usec / 1000000.0); 

printf("Size: %ld , Count: %ld Total: %ld ", 

bufsize, nbufs, nbufs * bufsize); 

printf(" Time: %.2f Rate (bytes/sec): %.2f(newline)",fend - fstart, 

(nbufs * bufsize) / (fend - fstart)); 

shutdown(sock); 

close(sock); 

} 

/* 

* Print usage info and exit. 

7 

usage() 

{ 

fprintf(stderr, "Usage: netpush [-v] hostname buffersize ^buffers #port(newline)"); 
exit(l); 

} 
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C.1.24 Netpushd Program Listing for a VAX running BSD 4.2 Unix 


r 

* 

* NOTE: THIS SOURCE CODE WILL ONLY RUN ON A 4.2BSD VAX. 

* 

* 

* Author: Steve Wall 

* Modified: Bohden K. Cmaylo 

* 

* netpushd. c 

* 

* Synopsis: netpushd [-v] #port 

* 

* "Netpushd" accepts connections on port PORTNUMBER (see netpush.h) 

* or portnumber if entered, 

* and reads in all the data that comes in on the socket. Basically, 

* netpush is a network /dev/null. 

* 

7 

^include <sys/types.h> 

^include <sys/socket.h> 

^include <netinet/in.h> 

^include <netdb.h> 

^include <stdio.h> 

^include "netpush.h" 

char buffer[MAXBUFSIZE]; /* buffer for storing data */ 

main(argc, argv) 
char *argv[]; 

{ 


long portnumber; /* variable port number */ 
int sock, /* our socket */ 

pid; /* process id of daemon (child) */ 

struct sockaddr_in server; /* address info */ 


r 

* Verbose mode? 
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*/ 

if (strcmp(argv[l], n -v n ) == 0) { 
verbose = 1; 

++argv; -argc; 

} 

/* 

* Check for command line arguments. 

V 

if (argc == 2) 

por tn umber =atoi(argv [ 1] ) ; 

if (argc > 2) 
usageQ; 


/* 

* Fork the child daemon process and exit the parent. 

7 

pid = fork(); 
if (pid === -1) { 

fprintf(stderr," Couldn’t forkQ(newline)"); 
exit(l); 

} else if (pid) 
exit(0); 

printf("%d" ,getpid()); 

gethostname(hostname,(int)sizeof(hostname)); 

I* 

* Set up the socket. 

*/ 

if ((sock = socket( AF_INET, SOCK.STREAM, 0)) < 0) { 
perror( n netpushd: Couldn’t open stream socket"); 
exit(l); 

} 

server .sin_family = AF_INET; 

server .sin_addr.s_addr = INADDR_ANY; 

if (argc != 2) 

server.sin_port — htons(PORTNUMBER); 
if (argc == 2) 

server .sin_port = htons(portnumber); 
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if (verbose) { 

printf(" (socket# %d)(newline)",htons(server.sin_port)); 

} 

if (bind(sock, &server, sizeof(server)) < 0) { 
close(sock); 

perror("netpushd: Couldn’t bind stream socket"); 
exit(l); 

} 

listen(sock,5); 

r 

* Loop, waiting for connection requests. 

V 

for 00 { 

int insock, /* socket that is requesting connect */ 

x; /* scratch variable */ 

long bytes_expected, /* # of bytes expected from remote */ 
bytes_recv = 0; /* # of bytes received so far * / 

insock = accept(sock,0,0); 
if (verbose) 

printf("%s: Accepted connection. (newline)", hostname); 


/* 

* Read the header from the remote host. The header tells us 

* the total number of bytes expected to be coming. 

V 

read(insock,szbuf,sizeof(szbuf)); 
bytes_expected = atol(szbuf); 
if (verbose) 

printf("%s: Expecting %ld bytes.(newline)", hostname, 

bytes_expected); 


r 

* Read the data. 

*1 

while((x = read(insock, buffer, sizeof(buffer))) > 0) { 
bytes_recv -f = x; 

if (bytes_recv > = bytes_expected) 
break; 
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} 

if (verbose) 

printf("%s: Sending 

bytes. (newline)", hostname, bytes_expected); 


verification 


Received %ld 


/* 

* Send verification of the number of bytes we received on 

* this end. 

7 

sprintf(szbuf, " %ld " ,bytes_recv); 
write(insock, szbuf, sizeof(szbuf)); 


/* 

* Clean up. 

7 

shutdown(insock); 
close(insock); 
if (verbose) { 

printf("%s: Total bytes received: %ld(newline)", 

hostname, bytesjrecv); 


} 

} 

} 

r 

* Print usage info and exit. 

7 

usageQ 

{ 

fprintf(stderr, "Usage: netpushd [-v] ^tport(newline)"); 
exit(l); 

} 
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C.1.25 Netpush.h Header File Listing for a VAX running BSD 4.2 Unix 


/* 

* Author: Steve Wall 

* Modified: Bohden K. Cmaylo 

* 

* netpush.h 


/* port # we’ll use */ 

/* maximum buffer size */ 


* Globals/defines for the netpush programs. 

7 

#define PORTNUMBER 1099 
#define MAXBUFSIZE 512000 

# define PRINTF if (DEBUG) printf 


char szbuf[50); 
char hostname[20]; 
int verbose; 
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C.1.26 Netpush Makefile 


# 

# Misc. makefile for 4.2BSD VAX. 

# 

DESTDIR = 

all: start netpush netpushd 

install: all 

mv start $(DESTDIR)/_start 
mv netpush $(DESTDIR)/netpush 
mv netpushd $(DESTDIR)/netpushd 

start: start.o getload.o 

cc -0 -s -o start start.o getload.o 

netpush: netpush .o 

cc -0 -s -o netpush netpush.o 

start.o: 

cc -c start, c 

getload.o: 

cc -c getload.c -DBSD4.2 

netpush.o: netpush.h 

cc -c netpush. c 

netpushd: netpushd .o 

cc -0 -s -o netpushd netpushd.o 

netpushd.o: netpush.h 

cc -c netpushd. c 

clean:; rm -f *.o start netpush netpushd 
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C.2 TCP/IP TUNING EXPERIMENT 


This report describes the results of some follow-up network performance tests 
run between Amelia and ICASE, two VAX 11/780 computers networked together over a 
satellite communications link. The first set of tests was performed on March 2, 
1986. The tests described here were desired because an earlier TCP/IP tuning test 
was restricted in scope due to technical problems. Some, but not all, of the tech- 
nical problems were resolved in this round of testing. 


C.2.1 Purpose 

The purpose of these tests is to see to what extent TCP performance can be 
improved by increasing the size of the send/receive windows. 

C.2. 2 Tests Performed 

The tests consist of the following: 

1. Netpushf LOCAL) was used to time memory-to-memory data transfers of 1,000 
bytes (x 250 transfers), 10,000 bytes (x 50 transfers), and 100,000 bytes (x 5 
transfers). The tests were run in one direction only, with netpush run on ICASE and 
netpushd on Amelia. Various window sizes between 2K and 28K bytes inclusive were 
sampled. (The default 4.2 BSD window is 2K bytes in each direction.) 

2. Ftp(l) was used to time disk-to-disk data transfers of 1,000 bytes (x 4 
transfers), 10,000 bytes (x 3 transfers), and 100,000 bytes (x 3 transfers), The 
tests were run in one direction only, with ASCII mode PUTs issued to ftp run on 
ICASE and ftpd was run on Amelia. 


C.2. 3 Testing Conditions 

The tests were run on the afternoon of Sunday, March 17. The computers were 
dedicated to running the tests: users were prohibited from logging on or running 

background processes, but system daemons were allowed to run. However, during some 
of the tests, a few users (at most 4) were logged in to Amelia. During the tests, 
the five minute load average on Amelia averaged 0.55, on ICASE it averaged 0.43. 

The network traffic on the Ethernet during testing was not assessed. Both computers 
have Interlan Ethernet controllers. 


C.2. 4 Kernel and Test Utility Modifications 

In order to control the size of the send/receive windows during network trans- 
fers, modifications were added to netpush , ftp, and the 4.2 BSD UNIX kernels running 
on Amelia and ICASE. 


89 


The modifications consisted of socket options to adjust and query the ceiling 
and size of the send/receive windows. It had been hoped that the rigid fixed-size 
received window advertisement algorithm used in the March 2 tests could be sup- 
planted with a more typical 4.2-style algorithm which recognized the larger win- 
dows. Unfortunately, the new code to achieve this wouldn't run on ICASE due to 
configuration problems. Due to scheduling restrictions the old fixed-size code was 
used. 

Data structures on Amelia were enlarged to accommodate windows >= l6Kbytes. As 
a result the crashing and hanging which restricted the previous tests was not a 
problem. Amelia only crashed once during the testing period, and it occurred while 
other users were on the system and not during an actual test. 


C.2.5 Test Results 

The raw test result files, as well as the kernel modifications and modified 
utilities are in the directory ~hahn/ptest/ame-icase2 on Prandtl and are described 
here : 


i ftp/ 

ftpd/ 

! netpush/ 

results/test . N 
results/report 
sys/ 


The modified ftp source files. 

The modified ftpd source files. 

The modified netpush. and netpusihd source files. 
Results of netpush with NK-byte windows. 

This report in troff (-ms) source format. 

The kernel modifications. 


Figure C.2.5-1 displays a graph of all the test results. The tests results 
data that follow give the numerical values of the effective transfer rates obtained. 
The five-minute load averages for the machines as reported by ruptime after each 
test are also given. Note that Kbytes = 1024 bytes. 


i 


! 
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Figure C.2.5-1 TCP/IP Graph of Test Results. 
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C.2.6 Netpush 


Window 

Kbytes 

Transfer Rate 

1,000 bytes 
bytes/sec bits/sec 

10,000 bytes 
bytes/sec bits/sec 

100,000 bytes 
bytes/sec bits/sec 

2 

3,039 

24,319 

2,974 

23,795 

3,090 

24,726 

4 

5,970 

47,766 

5,403 

43,224 

5,507 

44,062 

6 

9,619 

76,952 

8,454 

67,636 

- 

- 

8 

11,337 

90,702 

12,138 

97,110 

12,245 

97,967 

10 

11,742 

93,940 

14,526 

116,211 

14,876 

119,012 

12 

12,437 

99,502 

15,160 

121,285 

17,934 

143,472 

14 

21,834 

174,672 

18,635 

149,086 

20,024 

160,192 

15 

21,385 

171,086 

19,968 

159,744 

22,261 

178,094 

16 

20,885 

167,084 

22,563 

180,505 

23,889 

191,113 

17 

17,445 

139,567 

22,341 

178,731 

25,974 

207,792 

18 

14,044 

112,359 

23,386 

187,090 

24,606 

196,850 

20 

22,956 

183,654 

26,096 

208,768 

24,390 

195,121 

22 

17,099 

136,798 

21,939 

175,515 

26,455 

211,640 

24 

23,584 

188,679 

17,277 

138,217 

26,624 

212,992 

26 

17,705 

141,643 

20,584 

164,676 

20,729 

165,837 

28 

23,169 

185,356 

26,082 

208,659 

24,900 

199,203 
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C.2.7 FTP* 


Window 

Kbytes 

Transfer Rate 

1,000 bytes 
bytes/sec bits/sec 

10,000 bytes 
bytes/sec bits/sec 

100,000 bytes 
bytes/sec bits/sec 

2 

12,195 

97,560 

3,628 

29,027 

3,136 

25,094 

4 

16,129 

129,032 

3,236 

25,889 

2,604 

20,838 

6 

12,500 

100,000 

3,024 

24,198 

2,597 

20,777 

8 

16,666 

133,333 

3,105 

24,844 

2,597 

20,777 

10 

16,666 

133,333 

3,036 

24,293 

2,597 

20,781 

12 

12,500 

100,000 

3,102 

24,821 

2,596 

20,773 

14 

13,888 

111,111 

3,061 

24,494 

2,594 

20,754 

15 

13,888 

111,111 

3,080 

24,645 

2,596 

20,770 

16 

14,285 

114,285 

3,043 

24,345 

2,599 

20,792 

17 

17,543 

140,350 

3,064 

24,517 

2,599 

20,793 

18 

15,384 

123,076 

3,021 

24,169 

2,595 

20,766 

20 

17,543 

140,350 

3,090 

24,721 

2,595 

20,765 

22 

15,384 

123,076 

3,093 

24,744 

2,601 

20,808 

24 

17,543 

140,350 

3,043 

24,345 

2,591 

20,732 

26 

14,925 

119,402 

3,036 

24,293 

2,598 

20,788 

28 

11,764 

94,117 

3,021 

24,169 

2,597 

20,779 


"The problem preventing ftp 
and to the best of my knowledge, 
However, the data don't strongly 


from working during the March 2 tests was resolved, 
FTP used the enlarged TCP send/receive windows, 
suggest that this was the case. 
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C.2.8 Load Averages 


Window 

Kbytes 




Load Average 




users 

Amelia 

1 min 5 min 

15 min 

users 

1 min 

lease 
5 min 

15 min 

2 

5 

1.46 

1.07 

1.02 

i 

0.25 

0.31 

0.27 

4 

4 

0.37 

0.30 

0.31 

i 

0.55 

0.53 

0.34 

6 

4 

0.49 

0.46 

0.37 

i 

0.61 

0.63 

0.47 

8 

5 

2.03 

0.88 

0.56 

i 

0.43 

0.34 

0.32 

10 

4 

0.45 

0.77 

0.66 

i 

0.81 

0.59 

0.44 

12 

5 

0.74 

0.84 

0.75 

i 

0.46 

0.55 

0.48 

14 

5 

0.37 

0.58 

0.64 

i 

0.77 

0.52 

0.46 

15 

1 

0.06 

0.22 

0.27 

i 

0.75 

0.62 

0.47 

16 

1 

0.11 

0.15 

0.21 

i 

0.05 

0.18 

0.32 

17 

1 

0.56 

0.30 

0.25 

i 

0.23 

0.38 

0.38 

18 

5 

0.20 

0.69 

0.65 

i 

0.61 

0.45 

0.39 

20 

1 

0.12 

0.15 

0.19 

i 

0.17 

0.19 

0.28 

22 

1 

0.06 

0.25 

0.26 

i 

0.09 

0.22 

0.28 

24 

2 

0.42 

0.42 

0.36 

i 

0.13 

0.37 

0.37 

26 

4 

1.54 

1.03 

0.65 

i 

0.56 

0.53 

0.47 

28 

5 

0.44 

0.66 

0.70 

i 

0.38 

0.44 

0.45 
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C.3 LHCP TCP/IP VERSUS XNS PROTOCOL EXPERIMENTS 


This report describes the results of the LHCP network performance tests run 
between two identical IRISs on the LHCP network using two different protocols. 


C.3.1 Scope 

The scope of these performance tests was to observed which protocol performed 
better over Ethernet, 224kbps, and 56kbps communication links. Each communication 
link was tested with either no transport delay or with an introduced satellite 
transport delay. 


C.3. 2 Testing Conditions 

Two dedicated IRIS workstations were required for each test. Each workstation 
had an identical software and hardware configuration. During a test, each worksta- 
tion had installed either an XNS or a TCP/IP protocol implementation for remote 
communication. Other components included: Ethernet, Vitalink VB/ls, and a Satellite 
Delay Simulator. The Ethernet was either the main NAS Ethernet, or a local Ethernet 
when using the Vitalink VB/1 for a communication link. The Satellite Delay Simu- 
lator provided clocking and transport delay when required. These tests were per- 
formed in January 1986. 


C . 3 • 3 Tests Performed 

The test matrices that follow Figure C.3. 3-1 describe the definitions of the 
headings for the following tables of raw data collected. The headings are a brief 
description of the computers used, the type of simulated communication medium, the 
transport delay, and a suffix "r" to indicate when a real link was used. The format 
of the header column is: Field1-Field2/Field3/Field4 . An example "raw data" table 
follows : 

FILE (size in bytes) Field1-Field2/Field3-Field4 . . . 

BYTES DATA (in 1000 bytes per second) 


94 



Axis 

Description 

Y-axis 

The "File" identifies the "Y" axis of each table which consists of 
the number of bytes in a file for either a xcp or rep file transfer. 

X-axis 

The "X" Axis Heading Identifies a single type of test configuration 

"CELL" 

Each entry within the table not identified by the heading "File" is 
in units of "Kilobytes (1000) per second" transfer rate. 

COMPUTER 

Fieldl and Field2 - Description of Computer 

la 

An IRIS 2500 called annie running a SGI UNIX System 5. 

Iw 

An IRIS 2500 called wks running a SGI UNIX System 5. 

ELa 

An IRIS 1500 at LaRC running a SGI UNIX System 5. 

ILe 

An IRIS 1500 at LeRC running a SGI UNIX System 5. 

PROTOCOL 

Field3 - Protocol and type of communication link 

EX 

Ethernet using XNS Protocol 

ER 

Ethernet using TCP/IP Protocol 

2X 

224Kb /s using XNS Protocol 

2R 

224Kb/s using TCP/IP Protocol 

5X 

56Kb/s using XNS Protocol 

5R 

56Kb/s using XNS Protocol 

TRANSPORT 

Field4 - Transport delay 

0 

No transport delay 

1 

.01 second transport delay, terrestrial simulation. 

2 

.25 second transport delay, satellite simulation 

r 

suffix to indicate a real link, not simulated. 


Figure C.3.3-1 Definition of Raw TCP/IP vs XNS Test Data Matrices. 


C-A. 
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File 

Ia-Iw/EX/0 

Ia-Iw/2X/0 

Ia-Iw/ER/0 

Ia-Iw/2X/2 

Ia-Iw/2R/0 

Ia-Iw/2R/2 

Ia-Iw/5x/0 

300 



0.04 


0.03 


0.06 

1000 



0.2 


0.2 

0.1 

0.25 

3000 



0.6 


0.6 

0.4 

1 

10000 



2 


1.4 

0.9 

3.3 

27080 

5.4 

4.5 

5.4 

2.5 

3.4 

1.8 

2.7 

53248 

13.25 

10.6 

7.8 

4.4 

5.3 

2.7 

3.8 

117140 

16.7 

13 

14.6 

5.3 

6.5 

2.9 

3.8 

484839 

32.3 

18.7 

23.1 

7 

8.7 

3.2 

4.1 

969726 

36 

19.8 

27.7 

7.2 

9.3 

3.1 

4.3 

1507813 

37.5 

20.5 

29 

7.4 

9.4 


4.3 

300 



0.04 


0.04 

0.03 

0.06 

1000 



0.2 


0.2 

0.1 

0.33 

3000 



0.6 


0.6 

0.4 

1.5 

10000 



2 


1.7 

0.9 

2.5 

27080 

5.4 

5.4 

5.4 


3.4 

1.7 

3 

53248 

13.25 

8.8 

7.6 


4.8 

2.2 

3.3 

117140 

19.5 

11.7 

13 


6.5 

2.7 

3.5 

484839 

34.6 

18.7 

23.1 


8.7 

3.1 

4.4 

969726 

36 

20.6 

29.4 


9.2 

3.3 

4.4 

1507813 

37.5 

20.5 

31.4 


9.5 


4.4 

300 



0.04 





1000 



0.2 





3000 



0.6 





10000 



2 





27080 

5.4 


4.5 





53248 

13.25 


7.8 





117140 

16.7 


13 





484839 

34.6 


25.5 





969726 

33.2 


30.3 





1507813 

35.25 


29.6 






Figure C.3.3-2 Table 1 - TCP/IP vs XNS Tests Raw Data. 
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File 

Ia-Iw/6x/l 

Ia-Iw/6x/2 

Ia-Iw/5r/0 

Ia-Iw/5r/X 

Ia-Iw/5r/2 

Ia-ILa/2R/2r 

Ia-Il/EX/0 

Ia-ILe/2R/2r 

300 

0.05 

0.04 

0.04 

0.04 

0.02 



0.05 

1000 

0.25 

0.17 

0.14 

0.17 

0.1 

0.1 


0.1 

3000 

1 

0.8 

0.5 

0.5 

0.3 

0.3 


0.5 

10000 

1.1 

1.3 

1.4 

1.3 

0.8 

0.8 


1.1 

27080 

2.7 

2.5 

2.5 

2 

1.3 

1.7 

4.5 

2.2 

53248 

3.3 

2.6 

3.1 

2.8 

1.6 

2.3 

13.25 

2.7 

117140 

3.8 

2.5 

3.4 

3.3 

1.1 

2.5 

23.4 

2.6 

484839 

4.3 

3.4 

3.9 

3.9 

1.9 

3.3 

30.3 

3.2 

989726 

4.4 

3.6 

3.9 

3.8 

2 

3.3 

33.4 

3.2 

1507813 

4.4 

3.8 




3.2 

36.6 

3.2 

300 

0.06 

0.04 

0.04 

0.02 

0.02 

0.04 



1000 

0.33 

0.17 

0.17 

0.17 

0.1 

0.1 



3000 

1 

0.6 

0.5 

0.5 

0.3 

0.5 



10000 

1 

1.4 

1.3 

1.3 

0.8 

1.3 



27080 

3.4 

1.7 

2.5 

2.3 

1.2 

2.3 

5.4 


53248 

3.8 

3 

2.8 

2.8 

1.5 

2.5 

10.6 


117140 

3.9 

2.3 

3.3 

3.3 

1.1 

2.4 

19.5 


484839 

4.3 

2.8 

3.9 

3.6 

2.1 

3.3 

30.3 


989728 

4.4 

3.2 

3.8 

2.6 

2 

3.2 

33.2 


1507813 

4.3 

3 




3.2 

33.4 



Figure C.3.3-3 Table 2 - TCP/IP vs XNS Tests Raw Data. 
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C.3.4 Analysis of Selected Tests 

Various combinations of logical comparisons were selected to observe how the 
data transmission rates varied. The comparisons generally followed the below five 
guidelines: 

(1) If XNS protocol was being used, then the "xcp" file copy program was 

used. If TCP/IP protocol was being used, then the "rep" file copy program was used. 

(2) If a measurement was taken in one direction, that is machine A transfer- 
ring data to machine B, then the reverse direction was also measured. 

(3) Identical systems were compared at different link transmission rates. 

(4) Identical systems were compared with different transport delay rates. 

(5) All points were selected to indicate rate ranges. 

Graphs follow the below guidelines: 

(1) X-axis is in terms of bytes in a "rep" or "xcp" file copy operation. 

(2) Y-axis is in terms of Kilobytes (1000) per second. 

(3) The Legend titles follow the same format as in the raw data tables. 
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C.3.5 RCP & XCP via Ethernet and 224kbps, no delay 

This comparison indicated that "xcp" copied faster than "rep" over both 10Mbps 
Ethernet and 224kbps. On the Ethernet link, "xcp" was identical to "rep" for file 
sizes under “30,000 bytes, but the transmission rate increased to more than 10,000 
bytes per second, or 40£ faster, for file sizes greater than “30,000 bytes. 

On the 224kbps link, the transmission speed was degraded by link loading for 
both protocols. However, the XNS protocol reached over twice the transmission rate 
as TCP/IP, for large file sizes. 

Figure C.3.5-1 presents the graph of the results. 


•♦* l«-tw/Ex/0 H-tv/Er/0 ■*' U-lv/2x/0 « U-lw/2r/0 M*ximu»n 224kbps 



Figure C.3.5-1 RCP & XCP via Ethernet and 224kbps, no delay. 


99 


C.3.6 RCP & XCP via 224kbps and 56kbps, no delay 

This comparison again shows that the link loading is the primary mechanism for 
limiting the transmission speed of both protocols. However, in the 56kbps test, 
"xcp" shows only a slightly higher transmission rate than "rep". 

Figure C.3.6-1 presents the graph of the results. 


l*-lv/2x/0 

*°* t*-tv/2r/0 

*•* to-lv/3x/0 

•0- to-lv/3r/0 

Maximum 224kbps 

A- Mwdmum 96kbps 





Figure C.3.6-1 RCP & XCP via 224kbps and 56kbps, no delay. 
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C.3.7 RCP & XCP via 56kbps, with and without delay 

This comparison again shows that the link loading is the primary mechanism for 
limiting the transmission speed of both protocols. However, in the 56kbps test with 
delay, "xcp" shows almost double the transmission rate of "rep” for file sizes 
larger than 50,000 bytes. Also, "xcp" does not show as great of a drop-off of 
transmission rates due to the satellite delay as does "rep". 

Figure C.3.7-1 presents the graph of the results. 


l«-lw/5x/0 «• l»-l»/5r/0 «* l*-lv/5x/2 ^ U-lv/3r/2 M«ximum 56kbp» 



Figure C.3.7-1 RCP & XCP via 56kbps, with and without delay. 
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C.3.8 RCP & XCP via 224kbps and 56kbps, with delay 

In the 224kbps test with delay, "xcp" shows over double the transmission rate 
of "rep" for file sizes larger than 50,000 bytes. Also, "xcp" does not show as 
great of a drop-off of transmission rates due to the satellite delay as does "rep". 
Also, while the transmission rate for "rep" does not greatly increase when increas- 
ing the bandwidth from 56kbps to 224kbps, it more than doubles for "xcp". This 
shows a larger capacity of internal buffers for "xcp". Section C.2 (TCP/IP TUNING 
TESTS) indicated that larger internal buffers (window size) generally mean faster 
transmission rates. 

Figure C.3.8-1 presents the graph of the results. 


l*-lw/3x/2 U-lv/V/2 ♦ l*-h*/2x/2 *° l*-lv/2r/2 Maximum 56kbp* 



Figure C.3.8-1 RCP & XCP via 224kbps and 56kbps, with delay. 
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C.3.9 Conclusions 


With the results of the previous tests, it was concluded that the XNS protocol 
was indeed faster than the TCP/IP protocol over all conditions tested. However, it 
was also noted that both protocols were not tuned for satellite transport delays. 
One can assume that if indeed both protocols were tuned for a satellite delay, then 
XNS will still out perform TCP/IP. 
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APPENDIX D 


LHCP REMOTE MONTHLY REPORTS 


Each of the remote sites, Colorado State University, Langley Research Center, 
and Lewis Research Center, was asked by the NAS Projects Office to send a monthly 
report to NAS. This monthly report was to describe the status of each site in its 
progress with using the NAS as a remote facility. Also included within their 
reports was to be descriptions and progress reports on CFD activity, so that the 
remote use of the Cray could be better understood with respect to file transfer and 
other requirements. Problems with either the communication links or workstation 
support were also requested, so that the LHCP group could resolve them. 

These reports were distributed to the NAS project personnel. Whenever a 
problem was observed within a report by the LHCP group, it was highlighted by the 
symbols **##. These problem areas were examined and resolved by the appropiate 
people, as noted by the highlighted symbols, when the LHCP group distributed the 
reports. 


D . 1 REMOTE STATUS REPORTS FROM CSU 


This appendix contains Colorado State University status reports from October 
1985 to the conclusion of their NAS grant in April 1986. Another reference to 
consult for the Colorado State University NAS activities is their final report for 
NAS, "Remote Access for NAS: Supercomputing in a University Environment," which was 
printed in April 1986 and is available through Colorado State University, Institute 
for Computational Studies, P.0. Box 1852, Ft. Collins, Colorado 80522. The NAS 
library also has a copy. 


D. 1.1 October 1985 Status Report for CSU 


To: Bohden Cmaylo 

From: Becky Olson 

Institute for Computational Studies 
Colorado State University, Fort Collins, Co. 

The work done in October was part of the effort to incorporate Cray's micro- 
tasking into a multigrid flow code which had previously been multitasked. There is 
quite a bit of work involved in the microtasking effort, because of the current 
restrictions in effect with that 'product'. (It is not yet an officially released 
and supported Cray product.) Obviously, we will not be able to test for speedup 
factor on the Ames Cray X/MP-12, but we are doing almost all of the code development 
on that machine. The code models viscous and inviscid 3-D flow through a channel 
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with a swept wing mounted on one wall. We are also investigating the use of locally 
embedded grid refinements in order to be able to model the full Navier-Stokes equa- 
tions with adequate resolution of the flowfield near the walls and corners of the 
3-D channel. This grid structure will also allow the patching together of thin- 
layer, full Navier-Stokes and Euler regions while retaining the multigrid conver- 
gence acceleration capability. Preliminary 2-D research will be carried out on the 
X/MP-12, while, for the complicated 3-D computations with very large memory require- 
ments, we anticipate using the Cray-2. 

We have also created various shell scripts on the Sun workstations. These 
shell scripts allow our users to get a file from Amelia, put a file on Amelia, 
submit a job to the Cray, and get the status of that job on the Cray, thereby elimi- 
nating the need for our users to logon to Amelia. These shell scripts use the 
4.2bsd remote commands such as rep and rsh. 

We have also got the latest version of PL0T3D running on our IRIS. Work is 
still being done to get the Sun's version of PL0T3D up to speed by continuing devel- 
opment of it. One particular area of development has been the addition of the parti- 
cle tracing code. Also particular areas of the sun code are being converted to the C 
language in an attempt to improve its speed. 

The constant failing of Vitalink that we had experienced earlier has been fixed 
by NAS's long haul communication group and Vitalink. The problem of response time 
on Amelia has also been fixed by the shell scripts, since there is no need to log on 
to Amelia anymore. The only problem related to the Cray computer was a compiler bug 
in the 1.13 version of CFT. The Cray analyst told us how to access the 1.14 version, 
and the problem went away. 

D.1.2 November 1985 Status Report for CSU 


To: Bohden Cmaylo 

From: Becky Olson 

Institute for Computational Studies 
Colorado State University, Fort Collins, Co. 

The effort to develop a microtasked version of the concurrent Navier-Stokes 
code (CNS3D) has continued. Some of the development could be done on the Ames 
X-MP/12, but since the microtasking package is not presently available on the 
X-MP/12 at Ames, most of the work was done on the X-MP/48 at Mendota Heights. Our 
multitasking experience indicates that microtasking is superior to macrotasking and 
we strongly recommend that it be made available at Ames both on the presently 
installed X-MP/22 (and the X-MP/48 which will replace it shortly) and on the Cray 2. 

We have also been in the process of installing a second Ethernet board to one 
of our Sun's. This will enable us to have our own internet network numbers instead 
of being part of Ames-NAS. This entailed upgrading the operating system and chang- 
ing the kernel to add the second device and changing the HOSTS file. It should be 
operational in another week. 
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Procedures have been written to post-process output files from Ames for display 
on our Sun workstations and for printing on our Printronix laser printer. 

Software has been written to obtain hardcopies of plots displayed on our Sun 
workstations. Software is being written to do the same from the IRIS. 

We are currently experimenting with photographing images from IRIS/Sun screens. 

Work on embedded gridding for 3-D flow computations is presently in progress on 
the IRIS. 

An abstract is in progress on "Multitasked Embedded Multigrid for Three- 
Dimensional Flow Simulation" - The text of this abstract will be forwarded to you in 
January . 

Amelia availability - In the past we have noticed problems with the availabil- 
ity of Amelia, but recently its availability seems to have improved. There is one 
remaining problem that could benefit from some attention; that is, sometimes over 
weekends and holidays, Amelia seems to be up but the Cray station package is down. 

If we had the capability to do a remote restart of the station package it would 
improve our productivity. 

We have requested a NAS sponsorship of the supercomputing applications local 
area network for connection to ARPANET. 


D.1.3 December 1985 Status Report for CSU 


To: Bohden Cmaylo 

From: Becky Olson 

Institute for Computational Studies 
Colorado State University, Fort Collins, Co. 

The second Ethernet board is up and operational. Surya is now a gateway to our 
network from NASA Ames. Our hosts file has been updated accordingly, and Prandtl and 
Mercury have also been put in the host file. The only restriction on NASA Ames part 
is the internet number ending with 98 cannot be used because that is Surya 's inter- 
net number on our network. 

The EMACS editor has been installed on the Sun workstations and now will be 
evaluated and also moved to the IRIS. 

We are currently developing an efficient algorithm (CNS3D) to be used for 
Navier-Stokes simulations of complex aircraft and turbomachinery geometries. The 
algorithm incorporates an explicit three-dimensional flow solver, embedded mesh 
refinement, a model equation hierarchy ranging from the Euler equations through the 
full Navier-Stokes equations, multiple-grid convergence acceleration and extensive 
vectorization and multitasking for efficient execution on parallel-processing com- 
puters. An abstract of this work has been submitted for presentation at the Tenth 
International Conference on Numerical Methods in Fluid Dynamics to be held this 
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summer. The text of this abstract has been forwarded to Ron Bailey, under separate 
cover. 

A code to do the embedded multigriding for use in the algorithm has been devel- 
oped on the Sun workstations/CSU Cyber 205 for a rectilinear cascade of finite-span, 
swept blades mounted between endwalls. The code is now operational on the Sun/Cyber 
205 system. This code is now being made operational on the NAS system. This will 
allow the code to use the large memory capability so that realistically fine meshes 
for this current turbomachinery test geometry can be generated and will allow exten- 
sions of the code to include complete aircraft and turbomachinery geometries. Due to 
the extent of down time for Amelia this month, this work has been delayed and will 
be continued through January. 

In order to further develop and verify the CNS3D code it would be very helpful 
to have access to the F— 1 6 geometry and some typical transport geometry if 
available. 

We have begun to develop new code and convert old code to run on the Cray 2. 

So far we have converted a library of I/O routines that we have found helpful in 
debugging code on both the Cray X-MP and the Cyber 205. Unfortunately, all of them 
used features not currently supported by the Cray 2 FORTRAN compiler. In addition 
to that library, a set of routines that interpolate efficiently between grid levels 
in multiple grid problems has been developed, with the Cray 2 as the target 
machine. That is, we have been careful to build into the code several parameters 
that can be adjusted if the long memory access time becomes a problem. The micro- 
tasking of existing code for the X-MP series has continued. 


D.1.4 January 1986 Status Report for CSU 


To: Bohden Cmaylo 

From: Becky Olson 

Institute for Computational Studies 
Colorado State University, Fort Collins, Co. 

We received a set of manuals for the Cray 2 from User Services. We've also 
received several user guides as well. Conversion of our codes from the Cyber 205 for 
use on the Cray 2 has been completed and was successful. 

Initial testing of the CNS3D code on the Cray 2 has begun. This code will be 
used for Navier-Stokes simulations of complex aircraft and turbomachinery flows. 

The algorithm incorporates an explicit three-dimensional flow solver, embedded mesh 
refinement, model equation hierarchy ranging from the Euler through full Navier- 
Stokes equations, multigrid convergence acceleration, and extensive vectorization 
and multitasking for parallel-processing computers. 

Development of grids for complex three-dimensional configurations is now under 
way on the Cray 2; previously only fairly coarse meshes could be generated because 
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of the memory limitations on available computers. The graphics capabilities of the 
workstations will be used extensively in examining and optimizing new grids. 

We are anticipating the installation of multitasking on the Cray 2 with ongoing 
research into parallel processing on a four-processor X-MP. Dan Pryor spent the 
week of Jan 20 at Cray Research in Mendota Heights working out some microtasking 
problems with several people there. The multiple grid Navier-Stokes code was micro- 
tasked almost completely. Sample runs showed wall clock speedup of 1.9 using two 
processors. Four processors were unavailable for use at that time. We think that 
with larger test cases we can come even closer to a speedup factor equal to the 
number of processors. We are setting some up now. 

We have been testing some of our home-grown utilities on the Cray-2, but have 
discovered some problems involving the use of Hollerith data. The 32-bit representa- 
tion of integers seems to cause problems when Hollerith data are passed as arguments 
to subroutines. We have several easy things to try before we decide what to do next 
about the problem. 

An abstract entitled "Large-Scale Flow Simulations on the Cray 2" is being 
prepared for submission to the First World Congress on Computational Mechanics to be 
held in the fall. 

Our IRIS has been upgraded to the turbo option, with 4 megabytes of memory and 
the floating point accelerator added. From initial testing, it appears the I/O speed 
has increased by a factor of 3 and the graphics by a factor of 2. We are now looking 
into the possiblity of adding another disk to the system. We are now at operating 
system 3.3. 


D.1.5 February 1986 Status Report for CSU 


To: Bohden Cmaylo 

From: Becky Olson 

Institute for Computational Studies 
Colorado State University, Fort Collins, Co. 

The expansion of the grid generation capability in the CNS3D code has been 
completed. This allows realistically fine meshes to be generated for full Navier- 
Stokes viscous calculations. Also available with this is the capability to embed 
meshes so that multigrid convergence acceleration can be achieved for realistic flow 
problems. 

A code to do three-dimensional incompressible viscous calculations has also 
been implemented on the Cray 2. Initially this code is being run for the internal 
flow through the hot gas manifold of the space shuttle main engines. 

Visual display of the grids and of the flow results is being accomplished by 
transferring the grid or output files back to the Sun workstations. The plotting 
can be done on either the Suns or on the IRIS workstation. This process of 
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transferring files and then plotting has thus far been acceptable although if faster 
transfer rates were available no one would complain. With our 56 kilobit connection 
to Amelia it takes about 8 minutes to transfer a 3055850 byte file from our Sun to 
Amelia using rep. FTP is much slower, taking 11 minutes to transfer the same size 
file. Using rep and the to2 command to transfer that same file from our Sun to the 
Cray takes 11 minutes. 

Our paper entitled "Multitasked Embedded Multigrid for Three-Dimensional Flow 
Simulation" has been accepted for presentation at the 10th International Conference 
on Numerical Methods in Fluid Dynamics. We are using the Cray 2 extensively in 
computing three-dimensional Navier-Stokes flows to be included in this work. The 
algorithm incorporates an explicit three-dimensional flow solver, embedded mesh 
refinement, model equation hierarchy ranging from the Euler through full Navier- 
Stokes equations, multigrid convergence acceleration, and extensive vector ization 
and multitasking for parallel-processing computers. 

One of our codes does not yet compile on the Cray 2, because of a bug in the 
compiler. The Cray analysts are aware of the problem, but fixes to the compiler have 
so far not corrected the problem. We are tracking the situation. Also the command 
"nohup" does not seem to be working on the Cray 2; when we use it in conjunction 
with executing code (as described in the NAS User Guide on page 4-8) and then logoff 
the Cray 2, execution is terminated. 

(USER SERVICES - Please submit SPRs for the Cray compiler bug and the Cray nohup 
command with Becky Olson of CSU as the submitter - Bohden) 


D.1.6 March 1986 Status Report for CSU 


To : Bohden Cmaylo 

From: Becky Olson 

Institute for Computational Studies 
Colorado State University, Fort Collins, Co. 

Bohden , 

Here is March's report and the final technical report. Other copies are being 
mailed to the appropriate people. Sorry the March is so late. We had a storm 
yesterday which played havoc with the power so all machines were powered off. I do 
apologize. 

Becky 
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March Monthly Report/Final Technical Report 
Long Haul Communications Experiment 
April 1985 - April 1986 

The experiment was designed to assist the NAS (Numerical Aerodynamic Simula- 
tion) Project Office in the testing and evaluation of long haul communications for 
remote users. The objectives of this work were: 

Use a foreign workstation to remotely access NAS so NAS could explore potential 
problems and find solutions likely to result from interfacing equipment commonly 
used by university and industrial investigators to the NAS facility. 

Provide NAS with a linkage to a large university-based computing facility which 
can serve as a model for a regional node of the (LHCS) long-haul communications 
subsystem. 

Provide a tail circuit to the University of Colorado at Boulder, thereby simu- 
lating the complete communications path from NAS through a regional node to an 
end-user . 

To meet these objectives ICS took delivery of a Sun-2 1 60 color workstation the 
first part of June. Another Sun-2 160 color workstation arrived the first part of 
July. 


The first problem encountered by NAS/ICS was the inability of the Sun work- 
station to run a graphics software package available on NASA's Silicon Graphics IRIS 
workstation. Becky Olson spent a week in May 1985 at NASA Ames learning about the 
graphics package and the IRIS. She spent the next month converting it to the Sun 
workstation so the communication experiment could take place. 

The 56 kilobaud line and the data service unit were installed the week of July 
29 through August 1 . By August 1 , NASA Ames and ICS were talking through the 56 
kilobaud line, providing NAS with a linkage to a university. 

The next phase of the objective was to determine if the 56 kilobaud line was 
adequate for actual development work and data and graphic file transfers. Julie 
Swisshelm, a graduate student in mechanical engineering, spent the week of August 19 
through 23 actually conducting computational fluid dynamics (CFD) runs at NASA Ames 
to have a base in determining the time it takes to run a CFD problem and transfer 
files locally at NASA Ames. 

The next week (August 26 through August 30) the CFD runs were done at ICS 
through the 56 kilobaud line where statistical data was accumulated to see if the 
line speed was acceptable. This data are being processed by NASA Ames to see what 
the difference is between on-site users and remote users. In September ICS took 
delivery of a Silicon Graphics IRIS workstation. This was added to our local area 
network and used also to access NASA Ames. 



By October most of the problems associated with the long haul communications 
experiment, such as the instability of Vitalink and the reponse time of Amelia, had 
been fixed and a test production mode was begun. 

During the next few months, an efficient algorithm (CNS3D) to be used for 
Navier-Stokes simulations of complex aircraft and turbomachinery geometries, was 
developed. A code to do the embedded multigriding for use in the algorithm was 
developed on the Sun workstations/CSU Cyber 205 for a rectilinear cascade of 
finite-span, swept blades mounted between endwalls. This code was made operational 
on the NAS system. This allowed the code to use the large memory capability so that 
realistically fine meshes for this current turbomachinery test geometry can be 
generated and will allow extensions of the code to include complete aircraft and 
turbomachinery geometries. Other code was developed and old code converted to run 
on the Cray 2. So far we have converted a library of I/O routines that we have 
found helpful in debugging code on both the Cray X-MP and the Cyber 205. Unfortu- 
nately, all of them used features not currently supported by the Cray 2 Fortran 
compiler. In addition to that library, a set of routines that interpolate effi- 
ciently between grid levels in multiple grid problems has been developed, with the 
Cray 2 as the target machine. That is, we have been careful to build into the code 
several parameters that can be adjusted if the long memory access time becomes a 
problem. A code to do three-dimensional incompressible viscous calculations has 
also been implemented on the Cray 2. 

During this time the first two objectives of the experiment were met. We 
discovered that the researchers preferred to do most of the editing on the local 
workstations and ship the code over as opposed to doing it at the remote site. 
Utilities were created that allowed the researchers to bypass any interaction with 
Amelia and move files directly from the local workstation to the Cray, and from the 
Cray to our local workstations. The researchers preferred to use the local worksta- 
tions and just submit files to the Cray. It was discovered that 56 kilobits was an 
adequate line speed but a higher speed would not hurt. Our calculations demonstrate 
a 56 kilobit connection to Amelia takes about 8 minutes to transfer a 3,055,850 byte 
file from our Sun to Amelia using the command "rep." The command "ftp" is much 
slower, taking 11 minutes to transfer the same size file. Using rep and the "to2" 
command to transfer that same file from our Sun to the Cray takes 11 minutes. 
Finally, the researchers preferred to generate the graphics files on the worksta- 
tions as opposed to generating them on the remote machine. 

The third objective, that of providing a tail circuit to Boulder, has not yet 
been accomplished. Completion of this circuit has been delayed by slippage in the 
schedules for LAN interconnections at both CU Boulder and CSU and by slippage in the 
schedule for the reconfiguration of the CATI -funded (Colorado Advanced Technology 
Institute) 56Kb link between the CU Boulder and CSU computing centers. To date, we 
have no indication that these delays are indicative of anything more than normal 
schedule slippage. Work is continuing, beyond the period of performance of the 
present grant, and should be complete by mid-summer. 

Elizabeth "Becky" Olson 
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D.2 STATUS REPORTS FROM LaRC 


This appendix contains Langley Research Center's monthly reports from October 
1985 to the present. Gordon Erlebacher has undertaken the responsibility of gener- 
ating the reports each month. The NAS User Services Manager, Lynda Haines, has 
undertaken the responsibility to collect, examine, and distribute the LaRC report to 
all interested parties after the conclusion of the LHCP. 


D.2.1 October 1985 Status Report for LaRC 

From: Gordon Erlebacher 
Mail stop 156 

NASA Langley Research Center 
Hampton, VA., 23665 

To: Bohden Cmaylo 

NASA Ames Research Center 
Moffett Field, CA. 

Bohden, 

Nasa Langley took possession of their first IRIS 1500 (to be upgraded to 2500) 
during the second half of the month of September 1985. Two weeks were required to 
boot up the system, due to a lack of information, as well as insufficient exper- 
tise. Since then, an increasing number of users have become interested and have 
been steadily applying the PL0T3D package sent to us by Pieter Buning to the visu- 
alization of their computer generated flow simulations. 

During my recent visit to Ames, the 224 kbps satellite link between the two 
centers (ARC and LaRC) was successfully established, and (to my knowledge) has not 
had any non-scheduled downtime. Typical transfer rates have been clocked at around 
3000 kBytes/sec for medium to large files (< 1 MByte). File transfers have been 
performed between Langley, Ames and Colorado, with no noticeable problems. 
Furthermore, codes transferred from Ames to Langley have so far been error-free. 

Shortly after my return from Ames various aspects of IRIS system administration 
have been examined. A VAX750 (name: ICASE) has been connected to the NAS net. It is 
accessible from IGOR and Amelia. Currently, the of problems encountered are as 
follows. 

1. The FTP daemon does not automatically start up at boot time, even though it 
can be started up manually. 

2. Mail does not work across the satellite link, or across our local Ethernet 
link to the ICASE VAX750. 
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3. We have not yet succeeded in booting up the system using the b: command. 

We currently type in the command: b:ipOa <C/R>. It works, so the matter has been 
pursued. 

Mr. Michael Fischbein has recently been hired and has, as part of his duties 
been actively researching the causes for the problems mentioned above. Further 
information can be obtained from him. 

The IRIS has in the month of October operated without any hardware failures. 
However, Mr. Fischbein is researching various methods of protecting the user and 
system software against such an eventuality. No conclusions have as yet been 
reached. To reiterate, the majority of IRIS users are using graphic tools to visu- 
alize their data. 

Several large source programs have been uploaded to Amelia with the intention 
of running them on the Cray X-MP. They will be ported to the Cray 2 as soon as it 
is available. These program will be run as test cases at Ames Research Center. Use 
of Amelia and Igor is still very minimal, even though a handful of people have 
already requested accounts. 

If you require further information, please let me know. 

Sincerely yours, 

Gordon Erlebacher. 


D.2.2 November 1985 Status Report for LaRC 


From: Gordon Erlebacher 
Mail stop 156 

NASA Langley Research Center 
Hampton, VA., 23665 

To: Bohden Cmaylo 

NASA Ames Research Center 
Moffett Field, CA. 

Bohden , 

In the month of November, usage of the IRIS has increased slightly, but as of 
now it is by no means saturated by our users. The primary use it is being put to is 
running Pieter Buning's package PL0T3D which has gained in popularity (no competi- 
tion). User's are waiting for the latest versions of Grafix and View to do more 
sophisticated analyses. 

The satellite link has been used primarily by myself to keep up with the daily 
activities of the NAS project. Communications are excellent. Several source files 
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were transferred down from Ames to the IRIS and executed with no problem. The 
transfer rates are still hovering around 3 kBytes/sec. 

Mike Fischbein has been working with the UNIX environment to tailor it to our 
needs. The only major problem of interest that was fixed this month is uucp which 
now works correctly between the IRIS and the ICASE VAX in the mode mail nameficase. 
Both the mail name@ica se and direct mail sending to Ames has not yet been tried. 
Miscellaneous files were removed from the system, including all ARC accounts except 
for the NAS accounts and those of Kehoe, Buning and Fouts. 

New software is now available on the IRIS. Mike has written a utility to 
convert formatted data to unformatted data to use as input to Buning 's PL0T3D. It 
has error checking and is fairly general. 

A couple of weeks ago, several accounts were requested for the Cray 2 by users 
not presently working on the IRIS. Consequently, it is surmised that in a month or 
two, when the Cray 2 is made available to us, that the Iris user base will increase 
and a host of new problems will surface. 

More information can be obtained by either sending mail to gerl! Clyde or 
msf! Clyde. Clyde is the new official name given to the IRIS; please update your 
host file accordingly. Contrary to the tradition at Ames, we have decided to name 
our workstations after some of our most prominent CFD researchers. 

Gordon Erlebacher 


D.2.3 December 1985 Status Report for LaRC 


From: Gordon Erlebacher 
Mail stop 156 

NASA Langley Research Center 
Hampton, VA., 23665 

To: Bohden Cmaylo 

NASA Ames Research Center 
Moffett Field, CA. 

Bohden, 

December can properly be termed the month of stabilization. The average number 
of serious users is in the neighborhood of 10. They use the machine on a regular 
basis for plotting and animation. However, we are slowly building up a Cray 2 user 
base who use the IRIS and the ICASE VAX to access the NASNET. Currently the IRIS is 
only accessible from the ICASE VAX or from its console, so that the small number of 
users is a bonus. 

Several large files have been shipped to Ames and manipulated (compile and 
linked) on the Cray 2 and Cray X-MP. The transfers were error free. 
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Mail can now be sent to Ames from the ICASE VAX, but not yet directly from the 
IRIS. The reasons for this are presenty unknown. A user on the IRIS can communi- 
cate with Ames by including the ICASE VAX in the mail path. 

A special guest account with a restricted number of commands has been imple- 
mented by M. Fischbein. The objective is to provide a minimum amount of protection 
against outsiders who might wish to break in. 

It as been observed by Tom Zang and myself that the station package on Amelia 
is very erratic and is prone to failures quite often. It is felt here that this can 
hamper Cray usage rather sever ly. Is there an alternative? 

Finally it must be mentioned that the NAS support group has been very helpful 
in providing for our needs and in answering the numerous questions asked by our 
user. Thank you. 

Gordon Erlebacher 


D.2.4 January 1986 Status Report for LaRC 

From: Gordon Erlebacher 
Mail stop 156 

NASA Langley Research Center 
Hampton, VA., 23665 

To: Bohden Cmaylo 

NASA Ames Research Center 
Moffett Field, CA. 

Bohden, 

Finally misfortune struck! Our IRIS 2500 upgrade arrived early in the month, 
and the spells of bad luck began. The upgrade came without a bootable tape, so the 
field representative had to bring his own. Then we found out that the IRIS could 
only be booted via an ASCII terminal for reasons I do not fully understand (Mike 
Fischbein can provide any amount of detail). After the departure of installer, we 
discovered we had forgotten to copy over the optional FORTRAN graphic libraries. So 
another 1.5 weeks were wasted while waiting for a fresh tape to arrive. Unfortu- 
nately, one day prior to the long awaited fortran tape, the disk crashed while Mike 
was executing makedevice. It was then that he found out that the new version of 
ipfex, utility which is indispensable to boot up the IRIS from the disk, had a bug, 
and that the previous released version was required. This version has arrived 
today, but has not yet been tested. You should check the software you have received 
with your IRIS 2500 upgrades to make sure that you have the old version of ipfex. 
Note that your problems are not as severe as ours since your IRISs are networked 
together, and should a disk fail, you could always reboot from another IRIS. 
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Tom Zang and A jay Kumar have entered production mode on the Cray 2. They are 
running jobs ranging between 4 and 12 million words each, and have recently started 
increasing their run times. We are all awaiting a more sophisticated compiler from 
Cray. 


Gordon Erlebacher 


D.2.5 February 1986 Status Report for LaRC 

From: Gordon Erlebacher 
Mail stop 156 

NASA Langley Research Center 
Hampton, VA., 23665 

To: Bohden Cmaylo 

NASA Ames Research Center 
Moffett Field, CA. 

Bohden, 

Usage of the IRIS has stabilized. Mostly, researchers are using PL0T3D to 
view their numerical data. As yet, no Cray 2 results have been visualized. 

Communications between the Iris and the NAS network has presented no problems, 
with the exception of the loss of transmission due to snow on the satellite dish. 
This resulted in a 2 to 3 day loss of Cray compute time. 

Recently, users have begun to use Prandtl for run-of-the-mill operations which 
do not involve the Cray 2. However, problems have manifested themselves when login 
on over the LHC. It is probably related to the delay in the transmitting/receiving 
characters across the link. The Langley user typically gets a timed out message 
from Prandtl. A fix to the problem is highly desirable to ease transfer of infor- 
mation across the NAS network. 

(USER SERVICES - Please submit an SPR for the above problem with Mike Fischbein of 
LaRC as the submitter - Bohden) 

A major concern among our Cray 2 users is file storage. Procedures to store 
information on tape are being developed at Ames. However, the maximum file size 
permitted on Amelia is around 40Mbytes. This should be increased if reasonable 
restart files are to be generated. Breaking up files into sections has been sug- 
gested, but is impractical considering the number of transfers we have to go through 
to get the information from Langley to Ames and/or back. 

(USER SERVICES - Please submit an SPR for the above problem with Mike Fischbein of 
LaRC as the submitter - Bohden) 
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More information can be obtained from Mike Fischbein (FTS 928-2396 § Langley). 

Gordon Erlebacher, NASA Langley Research Center 

D.2.6 March 1986 Status Report for LaRC 

From: Gordon Erlebacher 
Mail stop 156 

NASA Langley Research Center 
Hampton, VA., 23665 

To: Bohden Cmaylo 

NASA Ames Research Center 

Moffett Field, CA. 

Bohden , 

Use of the IRIS workstation during the month of March remained stable at about 
20 users. For the most part, plotting with PL0T3D is still the major activity. 
However, new software is being developed on two fronts. First, I have partially 
rewritten, and extended a program put together by one of our Co-ops last summer. It 
reads a file with stream- or vortex-lines and surfaces, and allows the user to 
visualize them. Unlike the static properties of PL0T3D and view, the user can 
interactively select the streamlines he wants to see on the object itself with the 
use of the mouse, as opposed to entering numbers at the console. Extensive use is 
made of dynamic memory allocation to conserve memory. Second, a student in the 
Theoretical Aerodynamics Branch is developing a program to plot vortex lines in an 
axisymmetric configuration. The motivation is to allow users to store a 2-D data- 
base, yet plot 3-D vortex lines with no loss of resolution, and without having to 
store variables on a 3-D grid. 

Mike Fischbein is currently experimenting with low level UNIX daemons that he 
is writing himself. He has developed the knowledge to develop the "talk" routine 
from scratch on a UNIX 4.2BSD system. His progress could potentially affect our 
future network communications. 

The Cray 2, Navier, is usually accessed from the ICASE VAX, leaving Clyde for 
program development or flow visualization. Problems and potential problems that 
have, or will occur are as follows: 

1. Navier has been down a lot lately. If, as we are told, the problem is one 
of the cpu's malfunctioning, wouldn't it be possible to shut it down, and work on it 
during dedicated time? Substantial computing time has been lost to the users this 
month. Furthermore, during a working session, Navier often issues the message "not 
responding" without actually crashing. What does it mean? 
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*** (User Services - Please respond to Gordon with an answer - Bohden) 

2. I noticed that FTP was operational between Navier and Amelia. Does it work 
properly between Navier and your IRIS workstations? FTP between Navier and Clyde 
functions properly when changing remote directories, but Clyde freezes up as soon as 
a file transfer is initiated. Any clues? FTP has not been tried between Navier and 
the ICASE VAX. 

*** (User Services - Please respond to Gordon with an answer - Bohden) 

3. Recently, we have been able to communicate directly from one of our VMX 
VAXes to Euler and Europa, and from there to Navier, via DECNET. I do not know the 
details, and have not personally tried out any file transfers. Details will be 
provided in next month's report. 

4. File space is not an immediate problem. However, files of 40 Mbytes are 
common in the laminar transition problems we are working on. Sooner than expected, 
a file space crunch will occur again. Please prepare for it. 

5. All Cray users now have Prandtl accounts. Prandtl had been unreachable for 
several days, but I have recently been able to log on from Amelia. 

*** (User Services - This is currently SPR #860 - Bohden) 

6. According to User Services, DI-3000 will be available on Prandtl in the 
near future. The month of April will supposedly be spent fine-tuning the soft- 
ware. I personally possess a 2-D plotting package that uses DI-3000. The code 
could be make available to the system people working on the project. If possible, 
I'd like to participate in the testing of the software over the network. It would 
be interesting if I could interactively plot a file on one of our terminal using the 
software at Ames. This would be greatly appreciated. 

**# (User Services - Please respond to Gordon with an answer - Bohden) 

This concludes the report. 

Gordon Erlebacher, Computational Methods Branch 
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D.2.7 April 1986 Status Report for LaRC 


From: Gordon Erlebacher 
Mail Stop 156 

NASA Langley Research Center 
Hampton, VA. 23665 

To: Lynda Haines 

NASA Ames 
Moffet Field, CA. 


April report on the usage of NAS from Langley 
Dear Lynda, 

This month's report is divided into three sections. First, routine problems 
with the IRIS workstation are discussed. Second, an brief overview of our current 
communication links with the NAS computer complex is presented, and third, some of 
the difficulties encountered by users of Navier are elaborated on and suggestions 
for further improvement are made. 

Iris workstation 

As a protection against disk failure, incremental backups of the file system 
are performed every evening, with a full backup at the end of every week. 

New software has been downloaded from wkOI out at Ames. Specifically, your 
version of EMACS and version 3.4 of PL0T3D. Documentation is now being distributed 
to the users. Eric Hibbard has help with the installation of ArcGraph on our 
system. This package has already been tested in conjunction with the recently 
released version of GAS, made available by P. Buning on his recent visit to 
Langley. During his stay, he interacted with IRIS users and fielded questions on 
the various graphic software currently available. 

Communications 

Presently, there are two paths to Navier. Remote logins are routinely per- 
formed from the ICASE VAX or from Clyde (IRIS) across NASNET. However, this route 
is impractical if listings of source code, or short listings of output files are 
desired, since a tape transfer from ICASE to another VAX is required to bring the 
files back to our main complex. To remedy the situation, accounts were given to the 
Cray 2 users on Earth, which is accessible from Amelia. A file transfer from Navier 
proceeds as follows: 

1. Execute toame or touts to transfer file from Cray 2 to either Amelia or 
Prandtl. (FTP can be used as well) 

2. From the VAX, FTP the file to earth VMS VAX. 
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3. Telenet to the VAX and copy the file over the one of two VMS VAXes at 
Langley, across DECNET. From there, they can be directly routed to the printer. 

The process is long and involved, but nonetheless faster than using tapes. On 
the other hand, large files are more easily managed with tapes. 

If NASNET is unavailable, a remote login from our VMS VAXes through Earth 
should be possible, although it hasn't been tried out. If both DECNET and NASNET 
are down, we can still access Amelia and Prandtl through remote dial-in. In the 
last month, we have found out that if Navier is inaccessible to us, it is also 

inaccessible to the users at Ames. The major improvement we feel is important in 

the area of communications is to speed up the transmission rate across the satellite 
link. Presently, a 1 megabyte file can be transferred over to Langley from Ames in 
about 10 minutes. 

***** LHC: Can anything be done now to improve their file transfers? 

***** —Haines 

Graphics 

In the last 2 weeks of this month, concern has grown over the subject of 
graphic representation of the data bases generated on Navier. The solution Zang and 
myself have adopted, is to run a separate program on the Cray 2 which extracts 
subsets of the data base. We then send this subset to the IRIS or to Clyde where it 

is plotted up. With the advent of DI3000 and ArcGraph on Prandtl and the Cray 2, 

graphic metafiles can be generated at Ames and sent down directly. 

Difficulties with Navier 

The following list of problem areas reflects the small NAS user community at 
Langley. It has been communicated to Leslie Chow on her visit to Langley on May 
1st, 1986. 

1. A message command should be installed on Navier to provide users with 
information on system problems (both hardware and software). It could also be used 
to inform the users about special features available on the new compilers and 
linkers as they become available, instead of letting them find out by more devious 
means. For example, the open statement in Cray FORTRAN does not account for unfor- 
matted I/O, or if it does, it is not properly documented. It is more than likely 
that this will be remedied in a future compiler, but unless we are informed, how 
will we know? 

***** i will ask Operations and Development to check into how we can 
***** best transmit this information. — Haines 

2. The /tmp files has been heavily abused lately. Files of over 500 Mbytes 
sometimes reside there for days on end. As a result, Langley jobs have crashed a 
couple of times due to insufficient disk space. This problem occurred in the light 
of the Langley disk crash when most of our files were lost. The disk was taken back 
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to Cray with no replacement for the Langley users. Our file space was reduced 
accordingly. This brings up the next item. 

***** Abuse of /tmp will no longer be tolerated. If you see evidence 
***** 0 f abuse, please send a message with the pertinent information 
***** fo me f 0r action. — Haines 

3. In the event of a similar disk crash, it should be possible to allocate a 
portion of the tmp space to the affected organization. This would in a sense impose 
an equal file space restriction on all the users. 

4. Several times, we have noticed one or two users running three or four long 
batch jobs simultaneously. To prevent a total saturation of the system, we propose 
to limit the maximum number of batch jobs to two per user, if their time limit 
exceeds 1 hour, for example. 

***** | w in ask Operations and Development to check into #3 and 
***** # 4 . —Haines 

5. We have been adversely affected by the HYPERchannel problems between Amelia 
and Navier. As a result, users typically log in to Navier through Prandtl, although 
its HYPERchannel link the the Cray is not fully reliable either. 


D.3 STATUS REPORTS FROM LeRC 


This appendix contains Lewis Research Center's monthly reports from October 
1985 to the present. Dan Whipple has undertaken the responsibility of generating 
the reports each month. The NAS User Services Manager, Lynda Haines, has undertaken 
the responsibility to collect, examine, and distribute the LeRC report to all inter- 
ested parties after the conclusion of the LHCP. 


D.3.1 October 1985 Status Report for LeRC 


To: Bohden Cmaylo 
From: Dan Whipple 

LeRC NAS Remote Station 

Larry says you want a short report. 

1) Remote ASCII terminals hooked to IRIS via the Lewis CATV system so we can 
work from our desks 

2) Various new users joined to IRIS/UNIX and getting to know things better 
Hope this is sufficient for next week. 
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D.3.2 November 1985 Status Report for LeRC 


To: Bohden Cmaylo 
From: Dan Whipple 

November Events 

1) Remote ASCII terminal access to IRIS via LeRC LINK network 

2) November issue of LeRC computer newsletter had four page article on NAS and 
the equipment at LeRC complete with pictures 

3) Still waiting for modem parts to allow IRIS to move to bldg 5 


D.3.3 December 1985 Status Report for LeRC 


To: Bohden Cmaylo 
From: Dan Whipple 

LeRC NAS Remote Station 

1) IRIS down time due to lack of personal attention due to leave 

2) IRIS 2500 upgrade parts have arrived 

3) Expecting to move IRIS to Bldg 5 this month 

4) Received a copy of NAS Users Guide 

Dan Whipple FTS 297-5859 

D.3-4 January 1986 Status Report for LeRC 

To: Bohden Cmaylo 

From: Dan Whipple LeRC NAS Remote Station 

1) The parts necessary to move the IRIS workstation to building 5 have been 
shipped to LeRC and the move is now planned for the first week in February. 

2) The upgrade is still pending due to scheduling with the Detroit office of 
SGI. We will probably combine the upgrade with the move and subsequent checkout at 
the new location. 

3) The User Services office at ARC has been very helpful in various areas 
including the load of some IRIS tapes to overcome local procurement delays as well 
as help with an EMACS problem due to the VT100 emulation terminals we are using to 
access the system. 
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4) The IRIS has been used to access NAS computers and run some test cases of 
our codes. Additional users have been joined and are learning UNIX and will shortly 
be running additional codes. This effort should proceed rapidly as a sloppy but 
working way has been developed to link the IRIS with the LeRC central computers for 
file transfer. 

5) Scientific data base and graphics codes including PL0T3D are being imple- 
mented to support user codes and to provide a consistant interface across computer 
systems . 

6) A list of users has been compiled and sent to ARC for the initial distribu- 
tion of NAS user manuals. 


D.3.5 February 1986 Status Report for LeRC 


To : Bohden Cmaylo 
From: Dan Whipple 

LeRC NAS Remote Station 

Lewis Remote Station-February Report 

Various users have been joined to IRIS UNIX and NAS computers and are in the 
process of sending tapes to ARC to install their codes for running. Action to move 
the IRIS to Bldg 5, installing the upgrade, and interfacing to the LeRC computers 
are underway by the Computer Services Division at Lewis. 


D.3.6 March 1986 Status Report for LeRC 


To: Bohden Cmaylo 
From: Dan Whipple 

LeRC NAS Remote Station 

1) The modems necessary to move the IRIS to bldg 5 arrived and turned out to 
have the wrong baud rate. .estimate 30 day additional delay to get resolved; 2) 
because of (1) an area in bldg 142 was cleaned up and the full IRIS system, includ- 
ing printer, was set up and made available to users there on a temporary basis; 3) 
the entire system was backed up on tape and regular operations initiated; 4) major 
problem installing new Ethernet addresses. .new /etc/hosts file had format prob- 
lems.. all resolved within 1 day with excellent assistance from ARC; 5) finished and 
started to distribute a beginners writeup for LeRC/UNIX/IRIS users as its our first 
UNIX exposure; 6) requested and received Build 3 material from J. Vukelich; 7) SGI 
has scheduled 4/1/86 for the upgrade to the 2500 configuration. Expect to move to 
bldg 5 shortly after if replacement modems arrive and work; 8) user codes have been 
mailed (USPS type) to ARC and are beginning to sprout on the NAS system so we are 
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starting to see real users do real jobs at last. We have many users lined up and as 
they learn UNIX etc. the load should start to pick up. 

Dan Whipple-LeRC 


D.3.7 April 1986 Status Report for LeRC 


To: Lynda Haines 
From: Dan Whipple 

LeRC NAS Remote Station 

NAS-Lewis report for April 1986 

The following major events occurred this month 

1) The upgrade to a model 2500 IRIS was performed, then the ipfex version on 
SGI tape was bad, received correct tape next day from SGI, rebuilt the file system 
and got running with much help from Bill Kehoe, reworked about a dozen files to 
restore all system functions to their pre-upgrade state including remote communica- 
tion with ARC 2. 

2) Bill Kehoe downloaded the current version and documentation for PL0T3D. 

3) Started to notice many tcp errors which would sometimes lockup the system 
Execlan model 201 board ordered from SGI; also notified NAS of same. 

4) Our special modems arrived and were made to work so the entire pile was 
moved to Building 5 room 210 so we can have real access; however, the room wiring 
had to be redone as the initial job was performed by someone who put half the 
outlets on one circuit breaker and left the other five almost unused. Due to work 
elsewhere the air conditioning was off and room temp went up to 95° so we shut 
everything off. Finally got everything fixed and the system is fully operational. 

5) Installed the new Ethernet board in the IRIS but we are still getting the 
checksum errors sometimes followed by the link totally going down which if the user 
is on the console terminal hangs the system after the message 'EXOS PANIC' comes 
out. This is very often the result when trying to send anything more than a few 
lines across the link to/from ARC. This now seems to be the biggest problem we have 
as it inhibits file transfer of data and programs. 

***** Workstation Systems Administrators need to check with Dan on this 
***** problem. L. Haines 

Dan Whipple 5/1/86 
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APPENDIX E 


PROBLEM HISTORY/RESOLUTION 


The following sections deal with actual communication problems and their solu- 
tions. The problem reports are ordered chronologically from the initial connection 
on 6 August 1985 to the end of the LHCP on 30 April 1986. 


E.1 Symptom: CSU Vitalink Box Not Talking to ARC Vitalink Box 
Problem report #1 10am 6Aug85 

Submitted: Bohden Cmaylo/ARC/x5225 Closed: 6 Aug 85 
NAS SPR #702, severity=1 Assigned: Cmaylo 

Hypothesis: AT&T line down since DSU boxes appear ok on both sides. 

Actions : 

(1) 10am 6Aug85 - Investigated problem locally. Vitalink box and DSU unit 
this end OK. 

(2) 10:15am 6Aug85 - Called CSU. Their Vitalink box and DSU unit ok. 

(3) 10:30am 6Aug85 - called Boeing contact at MSFC. Out to lunch. Left 
message . 

(4) 10:45am 6Aug85 - went to Randy Parrella (McGuire not here) and asked 
about data network problem procedures. He explained about MSFC Trouble Center. 

(5) 11:00am 6Aug85 - called MSFC Trouble Center, explained situation, gave 
circuit number and appropriate contacts, requested a ticket number (but was denied 
because they did not know if it was a NASA circuit), and was told that they would 
get back to me. 

(6) 12:30pm 6Aug85 - Darren Norris (Boeing contact at MSFC) called and asked 
what's wrong. Told him and actions being taken. He said he would follow up 
actions. 

(7) 1:30pm 6Aug85 - Gunn of MSFC called and said line was fixed. The line was 
cut in Nevada. He waited until I verified communications. 
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E.2 Symptom: CSU VB/1 at ARC Crashing Every 2-3 Days 
Problem report #2 20 Sep 85 

Submitted: Bohden Cmaylo/ARC/x5225 Closed: 15 Oct 85 
MAS SPR #701, severity=1 Assigned: Cmaylo 

Hypothesis: VB/1 software problem. 

Actions : 

(1) 20Sep85 - frequencies of crashes increasing. Foo to push Vitalink for 
answers. Vitalink said to increase buffer sizes. Did, but CSU still crashed. 

(2) 20ct85 - CSU has new S/W for VB/1. Installed. Crashed later. 

(3) 150ct85 - Vitalink stated inactive 4.8Kb CSU and LeRC links caused buffer 
overflow. Deactivated those links. CSU now stable. If more than one link in a 
VB/1, then all links must be active, else forwarding buffers will eventually crash 
the box. 


E.3 Symptom: Initial LaRC Connection Not Working 
Problem report #3 20 Sep 85 

Submitted: Bohden Cmaylo/ARC/x5225 Closed: 1 Oct 85 
NAS SPR #700, severity: 1 Assigned: Cmaylo 

Hypothesis: Faulty installation of RCA equipment. 

Actions : 

(1) 20Sep85 - Tried loopback mode initially; could not loopback. Investigated 
problem using Vitalink boxes. Could communicate via satellite simulator, but not 
via COMTECHs. Asked RCA to investigate. 

(2) 23Sep85 - RCA appeared late in afternoon. COMTECH boxes needed to be 
internally clocked. Change made them work with loopback. 

(3) 24Sep85 - LaRC ready for connection, ARC not (loopback testing) 

(4) 25Sep85 - ARC ready for connect, LaRC not (dish realignment due to hurri- 
cane) 

(5) 1 Oct 85 - RCA reconfigured for LaRC. COMTECH box externally clocked at 
LaRC, needed to be internally clocked. After fix, connection established. 
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E.4 Symptom: Initial LeRC Connection Not Working 
Problem report #4 18 Oct 85 

Submitted: Bohden Cmaylo/ ARC/x5225 Closed: 21 Oct 85 

NAS SPR #699, sever ity=1 Assigned: Cmaylo 

Hypothesis: Faulty installation of RCA equipment. 

Actions: 

(1) I80ct85 - RCA established circuit late in the day... Did not work. Asked 
RCA to investigate COMTECH boxes. They stated could not do until next week. 

(2) 210ct85 - Asked A1 Ross to assist in COMTECH debugging. Assumed same 
clocking problem as LaRC. A1 Ross confirmed with Larry McFarland of LeRC. After 
both COMTECHs at LeRC fixed, connection was established (after McFarland jiggled 
some boards in the COMTECHs). 

E.5 Symptom: Very Long Delays to/from LaRC 
Problem report #5 9am 25 Nov 85 

Submitted: Bohden Cmaylo/ARC/x5225 Closed: 26 Nov 85 
NAS SPR #694, sever ity=2 Assigned: Cmaylo 

Hypothesis: Bad Satellite line to LaRC. 

Actions : 

(1) 9:00am 25Nov85 - Noticed long delays to/from LaRC. 

(2) 11:00am 25Nov85 - Investigated problem locally. ARC1 Vitalink box this 
end OK. 

(3) 11:15am 25Nov85 - Connected to LaRC Vitalink box; unit ok. 

(4) 1:00pm 25Nov85 - Contacted LaRC. They had not noticed anything. 

(5) 4:30pm 25Nov85 - Still Long delays. 

(6) 4:45pm 25Nov85 - Rebooted both Vitalink boxes; problem went away. 

(7) 10:00am 26Nov85 - Had Foo call Vitalink about problem. They did not know 
what did happen. 
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E.6 Symptom: LeRC Not Connected 
Problem report #6 9am 25 Nov 85 

Submitted: Bohden Cmaylo/ARC/x5225 Closed: 27 Nov 85 
NAS SPR #693, severity=1 Assigned: Cmaylo 

Hypothesis: Bad Satellite line to LeRC. 

Actions: 

(1) 9am 25Nov85 - Investigated problem locally. ARC2 Vitalink box this end 
OK. 

(2) 9:15am 25Nov85 - Could not connect to LeRC Vitalink box. Left message at 
LeRC for Whipple/McFarland. 

(3) 8:30am 26Nov85 - Called LeRC. Could not reach Whipple/McFarland. Towne 
left message. 

(4) 8:30am 27Nov85 - Tried to contact Whipple. Left another msg. 

(5) 11:10am 27Nov85 - Whipple called. Said that RCA did some work Monday. 
Said that McFarland tracking down what RCA did. Will return answer. 

(6) 1:00pm 27Nov85 - observed VB/1 ARC2. Noticed LeRC sporadic. Went to 097 
and observed COMTECH sm200. Everything looked ok. Noticed small green light was 
flashing on LeRC but not on LaRC. Reset both COMTECHs for LeRC. Tested connection 
to LeRC via rlogin. Worked!! 


E.7 Symptom: Problem with LeRC Connections 
Problem report #7 2 Dec 85 

Submitted: Bohden Cmaylo/ARC/x5225 Closed 4 Dec 85 
NAS SPR #692, severity=1 Assigned: Cmaylo 

Hypothesis: Bad Satellite line. 

Actions: 

(1) 9am 2Dec85 - Investigated problem locally. ARC2 Vitalink box this end 
OK. COMTECH box to LeRC faulting. Tried to contact LeRC and ARC ES; no luck, 
nobody anywhere. Left msgs for everybody. Contacted ARC ES later - they stated 
that no receive from LeRC coming in. 


128 



(2) 2:30pm 2Dec85 - Contacted RCA service center. They gave ticket // L536, 
circuit type 22*110), circuit // 8396. 

(3) 11am, 3Dec85 - RCA at LeRC. Waiting on cable (FO) from Goddard ES. 
Appears to be a fiber Interface problem. 

(4) 10am, 4Dec85 - Called RCA Service center. They stated problem fixed. 
Gave Goddard number (301 474 2330) as a future number to call for problems. LeRC 
was up. 


E.8 Symptom: Problem with LaRC/LeRC Connections 
Problem report #8 5 Dec 85 

Submitted: Bohden Cmaylo/ARC/x5225 Closed 11 Dec 85 
NAS SPR #691 , severity:: 1 Assigned: Cmaylo 

Hypothesis: Bad Satellite lines. 

Actions: 

(1) 1:30pm 5Dec85 - Televideo conference this morning. After conference, LeRC 
and LaRC connections unavailable. Investigated problem locally. ARC1/ARC2 Vital ink 
box this end OK. COMTECH box to LeRC faulting. Rebooted COMTECHs and VB/ls - no 
change. Tried to contact LaRC, LeRC and ARC ES; no luck, nobody anywhere. Left 
msgs for everybody. 

(2) 9am 6Dec85 - No LeRC/LaRC communication yet. Contacted ARC ES. LaRC line 
ok, LeRC line no receive. Left more msgs at LaRC and LeRC. Not returned. LeRC 
stated that communication was available for a while on 6Dec85 after RCA left. 

(3) 9am 9Dec85 - LeRC/LaRC still down. Contacted Bill Shinn at LaRC. He said 
he would investigate why LaRC down. Rebooted both VB/ls. LeRC came up, LaRC stayed 
down. COMTECHs show LaRC ok while LeRC had 50+-30 bers. Called ARC ES - they 
stated RCA working LeRC problem but LaRC looks ok. 

(4) 10:30am 9Dec85 - Called LeRC - they stated that they were up and connec- 
tion to Amelia was established. Could not confirm. 

(5) 12:30pm 9Dec85 - LeRC and LaRC both came up. LaRC came up after we 
rebooted the COMTECH and VB/1 box at LaRC and waited ~8 minutes. LeRC came up for 
some other unknown reason. 

(6) 4:30pm 9Dec85 - Checked connections. LaRC was up, CSU and LeRC down. 
Rebooted ARC2. CSU came up, LeRC stayed down. Called A1 Ross (ARC ES) and he said 
that at 2pm LeRC was weak and that RCA was still working on it. Said also that he 
would check 6:30am lODec on status of LeRC. 
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(7) 10am 10Dec85 - A1 Ross called, said LeRC fixed and televideo conference 
was over. Checked connections. LeRC up, CSU and LaRC down. Rebooted ARC1 and ARC2 
- CSU came up; rebooted LaRC COMTECH and LaRC VB/1- still down. LaRC contacted 
11:30, they rebooted COMTECH and VB/1, and they came up. 

(8) 8:30am 11Dec85 - LeRC down. LeRC stated they went down at 1:39pm PST. 
Rebooted both VB/ls at 10am, no change. Rebooted both COMTECHs and VB/ls at 11:35, 
LeRC now up. No rlogind at LeRC ... rebooting LeRC at 11:50. 

(9) 11:30am 11Dec85 - A1 Ross (ED) stated that RCA boosted power at both LeRC 
and ARC. Also realigned antenna at LeRC. Problem seems fixed now. 


E.9 Symptom: Problem with LaRC Connections 
Problem report #9 1 1 Dec 85 

Submitted: Bohden Cmaylo/ARC/x5225 Closed: 28Jan86 
NAS SPR #690, severity: 1 Assigned: Cmaylo 

Hypothesis: Bad Satellite lines. 

Actions: 

(1) 17:30pm 11Dec85: LaRC not on line. Rebooted VB/1, no change. Too late to 
get LaRC help. 

(2) 8am 12Dec85: investigated local connections, all seems ok. Hard to con- 
tact LaRC. Obtained slight help from Gordon Erlebacher in rebooting VB/1 at LaRC; 
no help. Still down. Asked Foo and Eisenman to continue investigation Friday. 

(3) 9am 13Dec85: Investigation proceeding. No complaints from LaRC. 

(4) 8am l6Dec85: LaRC still down. Asked A1 Ross to assist. Discovered at 
14:30 that primary COMTECH faulty. Asked A1 Ross to report and return dates of 
repair. 

(5) 2pm 19Dec85, Larry of RCA wanted 2-4pm for testing. Confirmed that LaRC 
COMTECH is bad. Switch board is bad. 

(6) 2Jan86, Larry of RCA repaired the primary COMTECH to LaRC and stated it 
was ok. LaRC went down at approx: 1630 that day. Primary COMTECH was again at 
fault. Called Ross for him to contact Larry of RCA. 

(7) 2pm, l6Jan86: Larry of RCA took LaRC primary COMTECH for repair. 
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(8) 2pm, 21Jan86: Larry of RCA returned LaRC primary COMTECH. Still appears 
faulty. 

(9) 3:30pm, 28Jan86: Closed via problem report #14. 


E.10 Symptom: CSU Down 

Problem report #10 23 Dec 85 

Submitted: Bohden Cmaylo/ ARC/x5225 closed: 23 Dec 85 


NAS SPR #698, severity: 1 


Assigned: Cmaylo 


Hypothesis: Bad AT&T line 
Actions: 

(1) 10am 23Dec85 - Becky of CSU called... cannot get on. Tried rebooting both 
VB/1 , no luck. Asked about modems. . .transmit light on, no receive light at CSU. 
Checked here, same situation. AT&T line appears down. Reported to CSU. 

(2) 10:30am 23Dec85, called MSFC trouble center to report fault. Ticket 
number received is 861828. They will call back. 

(3) 12:05pm 23Dec85, MSFC called back and asked to verify line up. Line was 
up. AT&T had replaced a jumper in Oakland Ca., which was wrongly removed. 


E. 1 1 Symptom: CSU, LeRC, and LaRC Down 
Problem report #11 6 Jan 86 

Submitted: Bohden Cmaylo/ARC/x5225 Closed: 5Mar85 
NAS SPR #685, severity: 1 Assigned: Cmaylo 

Hypothesis: Vitalink down 
Actions: 

(1) 8:30am 6Jan86: "ruptime" showed surya and icase down. Went into LHCP lab 

and saw error message on vitalink box: 

"Warning: ARC2 080002001328 PID: 1 1 02 code:2 time: (several) 

attempt to free CB without WRITE_CMPLT at line 0" 

Foo to investigate. 
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(2) Jiggled Ethernet cable for ARC1, then LaRC came back up. Eisenman to get 
techs to fix. This has happened several times before. 

(3) 10Jan86: Foo Lee stated that Anna Stevenson of Vital ink said that you get 
the warning message when you lose the clear-to-send (CTS) signal on the modem 
(COMTECH?) or due to a loose connection. 

(4) 13Jan86: Placed AB box for V.35 modem cable between ARC2/LeRC, COMTECH 

modem, and satellite simulator, to assist in cable switching for testing. Want 
Bendix to purchase another AB box for ARCI/LaRC. Also want Bendix to check/fix 
cable ends. 

(5) 5Mar86: Bob Renfro/Bendix replaced and/or repaired V.35 cables. Pat 
Jacquemet/ETI checked/repaired Ethernet drop lines. Item appears closed. 


E.12 Symptom: LeRC Signal in Flux from ARC Signal 
Problem report #12 8 Jan 86 

Submitted: A1 Ross/ARC/x6519 Closed: 11Mar86 

NAS SPR #684, severity: 1 Assigned: Cmaylo 

Hypothesis: 1/2 of COMTECH down 
Actions : 

(1) 8:30am 8Jan86: Larry of RCA called and said that A1 Ross called him and 
said that LeRC signal was in flux. He said to turn off whatever COMTECH modem was 
on, and have A1 check on the resultant signal. Turned the backup modem off, which 
resulted in a better signal. A1 will contact Larry to further fix the problem. 

(2) 2pm, l6Jan86: Larry of RCA took LeRC modem for repair. 

(3) 3pm, 29Jan86: Larry of RCA returned modem. I had to go to a branch 
meeting, therefore, I could not check on status of installation. 

(4) 8:15am, 30Jan86 : See LHCP Problem #15. LeRC modem still bad, except that 

it is the backup modem this time. 

(5) 8-10am, 11Mar86: Larry Simonis/RCA + Marty Suzuki/Bendix replaced sync 

board during a video teleconference. They left after checking out both LaRC and 
LeRC systems. 

(6) 10:30am, 11Mar86: LaRC/LeRC not up after video teleconference com- 

pleted. LeRC was visible on the Vitalink equipment (see LHCP Prob 17), while LaRC 
was not (see LHCP Prob 18). Therefore, the LeRC modem problem is considered fixed. 
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E. 13 Symptom: LeRC Down 

Problem report #13 22 Jan 86 

Submitted: Trevor Eisenman x5485 Closed: 22Jan86 
NAS SPR #688, sever ity=1 Assigned: Cmaylo 

Hypothesis: Signal loss from LeRC. 

Actions: 

(1) 10:00am 22Jan86, on checking LeRC local lines, the COMTECH showed fault 
lights on indicating receive signal loss. Called A1 Ross to check on incoming 
signal, which was none. A1 Ross to call Goddard and carry on checking. 

(2) 11:30am, 22Jan86: A1 Ross called and said that high winds moved satellite 
dish at LeRC. Satellite dish was repositioned and communication reestablished. 


E. 14 Symptom: LaRC Down 


Problem report #14 27 Jan 86 

Submitted: User Services x6771 (Ellen Figueira) Closed: 28Jan86 
NAS SPR #687, severity:: 1 Assigned: Cmaylo 

Hypothesis: Signal loss from LaRC. 

Actions: 

(1) 9am, 27Jan86: User Services called and stated that 2 LaRC callers said 
that they could not connect with NAS. 

(2) 9:10am, 27Jan86: Checked out VB/1. Appeared ok but no LaRC connection. 
Called A1 Ross/ARC Earth station to check on LaRC signal. He stated signal was weak 
and would followup with RCA. Reported back to User Services. 

(3) 9:40am, 27Jan86: A1 Ross called and said that RCA said that LaRC dish was 

covered with snow and that they would not sweep it away. Reported back to User 

Services . 

(4) 9:55am, 27Jan86: Called Bill Shinn at LaRC (Brad Ball not in) and stated 

problem. He said he would get someone on it and call back. He called back later 

and said that they wanted to wait until the next day to see if new snow fell. 
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(5) 8:15am, 28Jan86 : called Bill Shinn at LaRC. He said that problems existed 
in turning off the dish, because of microwave hazards. Said he would call back in 
an hour after he got hold of Frank Thames. 

(6) 11:30am, 28Jan86. Called Shinn who stated that the Shuttle disaster, 
which occurred earlier, postponed action on clearing dish. 

(7) 1:35pm, 28Jan86 : Shinn called and said that dish was cleaned. Still no 

LaRC connection. Checked with Ross and he said that LaRC coming in ok now. He will 
contact RCA to indicate possible COMTECH problem here. 

(8) 3pm, 28Jan86: Mike Suzuki of Bendix called and said John of RCA here to 
inspect COMTECH modems. John fiddled around and stated that the attenuation for the 
LaRC backup was set too high. Asked him to check both primary and back up. Did 
both, now everything appears ok. 


E . 1 5 Symptom: LaRC 4 LeRC Down 
Problem report #15 30 Jan 86 

Submitted: Bohden Cmaylo x5225 Closed: 31Jan86 

NAS SPR #686, severity: 1 Assigned: Cmaylo 

Hypothesis: Signal loss from LaRC 4 LeRC. 

Actions: 

(1) 8:15am, 30Jan86: Checked both LaRC and LeRC; Both were down. Called A1 
Ross, x6519, and he said that LaRC had been down since 7:15 and he had called it 
in. I told him that LeRC was down, and he stated that it was up at 6:30 when he 
last checked. The LeRC db level was 8; should be 16. I called Larry McFarland of 
LeRC and stated the problem. I also gave A1 Larry's phone at LeRC. 

(2) 8:50am, 30Jan86: LaRC connection now up. Called A1 Ross/ ARC Earth station 
to check on LaRC 4 LeRC signal. He stated LaRC signal was weak (12db) but accept- 
able. LeRC still bad. 

(3) 9:30am, 30Jan86: Received a call from MSFC. It seems that Alan Black from 
LeRC called them and they did not know about the LHCP circuits but wanted to be in 
the loop. I told them that I was the end user, and that my contact was with A1 Ross 
at ARC, Brad Ball at LaRC, and Larry McFarland at LeRC. They then called Ross. 

Ross to straighten out problem reporting procedures with MSFC/Goddard/ED. 

(4) 8am, 3Uan86: Called A1 Ross who said that LeRC signals ok. Checked 

COMTECH and discovered that IF Loop switch was set in backup modem and that backup 
modem was set to online. (This caused confusion in the LHCP Electronics Lab for 
several days due to loopback being shown on the Vitalink ARC2 box). Switched off IF 
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loop and backup modem went into fault mode. Switched offline backup modem and 
placed prime online with IF loop set, detected loop condition on ARC2-VB/1. Turned 
off IF Loop on the prime and connected to LeRC at approx 8:45am. 


E.16 Symptom: CSU Down 


Problem report #16 20 Feb 86 

Submitted: Becky Olson (303 491-6952) CLOSED 20 Feb 86 
Assigned to: Bohden Cmaylo 

NAS SPR #786, sever ity=1 Assigned: Cmaylo 

Hypothesis: 56Kb AT&T line down 

Actions: 

(1) 9am, 20Feb86: Becky called stating "Is Amelia down?." I checked and said 
no. She then stated that she could not see our vitalink box from her vital ink box, 
so I checked ARC2 and discovered that a) LeRC was still up and b) CSU was not visi- 
ble. I asked Becky to check out her modem xmit and recv lights, and she stated that 
the xmit was on and the recv was not. I said that that indicates a line problem. I 
then reported the problem to user services for SPR tracking and requested that Paul 
Robinson call me. 

(2) 9:30am, 20Feb: Larry Flynn and I checked our DSU/CSU modem. It also 
showed xmit on but no recv. Called MSFC trouble center to report that the 56Kb line 
was down (at 9:50am). Ticket #863073 was given for the problem. Notified CSU. 

(3) 13:05pm, 20Feb: Called MSFC and asked for status. They replied that a 
California mudslide carried away the carrier and the estimate for repair is 

24 hours. Notified CSU. 

(4) 16 :10pm, 20Feb: Noticed CSU is up. Called MSFC and asked for status. 

They said no change from previous status. They stated that since CSU is up, they 
want to close ticket. I said ok, but I will call next week to find out final 
status. Item is considered closed. 

(5) MSFC said Monday, Feb 24, that AT&T routed the circuit around the slide. 

No further interruptions should come from that slide. 
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E . 1 7 Symptom: LeRC Not Communicating with NAS Network 


Problem report #17 Opened: 11 Mar 86 

Submitted: Dan Whipple/LaRC Closed: 11 Mar 86 

NAS SPR #896, severity: 1 Assigned: Cmaylo 

Hypothesis: bad /etc/hosts information 

Actions: 

(1) 8:30am 11Mar86: Dan Whipple called user services and said that he could 

not talk to NAS. User Services then called me. I then called Dan. He said that 
he used the "localhosts" and "hosts" file as instructed by J .Lekashman/GE but noth- 
ing works. He also tried to use the old tables, which also did no good. I stated 
that I remembered that the IRIS required that the local address be first in the 
table. 

(2) 10:30am, 11Mar86: Since local help was not available, I talked to Mike 

Fischbein/LaRC. He said that in order to use the tables as supplied by J. 
Lekashman/GE, you needed to replace all tabs by a space and have no more than 

1 space between the address and the aliases. I left a message at LeRC for Dan to 
that effect. 

(3) 11:30am, 11Mar86: Spoke to Kehoe about problem. He said that he has a 

fix where the local host need not be the first item and that a easy fix should be 
placed within the IRIS system to accept white space instead of a single blank. 

(4) 12:45pm, 11Mar86: Spoke to Dan Whipple/LeRC, who just got my message and 

was leaving to try to bring up the IRIS. 

(5) 2:49pm, 11Mar86: E-Mail from Dan Whipple/LeRC indicating connection. He 

also said that all comment lines must be removed, in addition to the above require- 
ments. Item closed. 
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E.18 Symptom: LaRC Not Communicating with NAS Network After 

Video Teleconference 

Problem report #18 Opened: 11 Mar 86 

Submitted: Mike Fischbein/LaRC Closed: 11 Mar 86 

NAS SPR #897, severity=1 Assigned: Cmaylo 

Hypothesis: Bad Satellite link switchover to NAS circuits 

Actions : 

(1) 9am 11Mar86: Mike Fischbein called me and said that he could not sign on 

to NAS. I replied that there was a message sent out last week to him (and all other 
NAS users) that a video conference was scheduled this morning and also the next. I 
said that I would check it out after the circuits were restored. 

(2) 10:30am, 11Mar86: Checked LaRC link, it did not work. I checked out all 

our local equipment (Vitalink and COMTECH) and the status looked ok. Called 
Mike/LaRC who also said all local equipment looked ok. Next step is to check out 
Earth stations at both ends. 

(3) 11:30am, 11Mar86: Finally reached ARC Earth station (AL Ross). He stated 

signals to/from LaRC ok. He mentioned that RCA was over doing some work on the 
COMTECHs and would see what they had done. 

(4) 11:55am, 11Mar86: Ross/ARC called and said for me to talk to Larry 

Simonis/RCA. Spoke to him and he mentioned that he did some testing on the LaRC 
COMTECH box when he fixed the LeRC COMTECH box. I went down to room 097 to check on 

some information that he gave me, but it still did not work. He said he would be 

here within 20 minutes. 

(5) 12:15pm, 11Mar86: Larry/RCA arrived. Went down to check on boxes. 

Appeared that LaRC backup was set to test mode. Reset to normal, still did not work 
(via rlogin to larc from amelia). Larry/RCA set primary modem off line, then con- 
nection worked. He then switched both demod boards from the primary to backup, 
which caused the connection to then work from either the primary modem and the 
backup modem. 

(6) 1pm, 11Mar86: Larry said that there still exists the problem that the LaRC 
link may go down. If it does, he said to switch over whatever modem was on to the 
other modem. If it does it again, he will want to switch over some boards to the 
LeRC modems to see if the problem switches with the boards. 
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E. 19 Symptom: LeRC Not Communicating with NAS Network 
Problem report #19 Opened: 6 Mar 86 
Submitted: A1 Ross/x6519 Closed: 6 Mar 86 

NAS SPR #876, severity: 1 Assigned: Cmaylo 

Hypothesis: Bad Satellite link. 

Actions: 

(1) 8:30am 6Mar86: A1 Ross, ARC Earth Station technician, called me and stated 
that the receive signal from LeRC is at 1DB, which is 11DB above the required 
margin. A1 notified MSFC at 8:15am 6Mar86 and MSFC is working to correct the prob- 
lem. No estimate of repair was given by MSFC. (MSFC will notify A1 Ross of the 
situation and give him a ticket number). This is a #1 SPR since the LeRC link to 
ARC is dead. 

(2) 10am 6Mar86: Marshall Space Flight Center (MSFC) returned A1 Ross's 

initial trouble call and gave him ticket number 863383 at approx 9:30am. MSFC 
insisted the problem was with the SUN-OUT that was scheduled for this week. 

(3) 12:15pm 6Mar86: At approx 12:00noon, MSFC reported to A1 Ross/ ARC that the 

link was up, however, Goddard Space Flight Center (GSFC) did not report to MSFC what 
the problem was. Item is closed with no solution reported. 


E.20 Symptom: LaRC Not Communicating with NAS Network 
Problem report #20 Opened: 12 Mar 86 
Submitted: Cmaylo x5225 Open 

NAS SPR #903, severity: (2) 4 Assigned: Cmaylo 

Hypothesis: Bad COMTECH modem 
Actions: 

(1) 13:50pm, 12Mar86: Did check with ruptime and discovered "ICASE" at LaRC 
was down 13 minutes. Checked if could connect to the "larcOI-ec" IRIS, nol Checked 
Vitalink ARC1 box, it did not see LaRC box. See LHCP Problem #18 (NAS SPR #897) 
sub-item 6 for discussion of probable fault. 

(2) 14:00pm, 12Mar86: Went to room 097 to check on COMTECH modems. All 

looked ok. Reset "demod" from the backup COMTECH to the primary COMTECH. LaRC came 
back up on line. Marty Suzuki/Bendix was with me so he will call Larry Simonis/RCA 
to report problem. 
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(3) 22Apr86: Larry Simonis/RCA stated that since the satellite service is to 

go away in a couple of months, that it is not necessary to fix the backup modem. 

The reason is that RCA contracted for the service, and NAS is getting the service, 
so there is no need to do anything. The backup capability exists in that there is 
the other backup modem for the LeRC circuit, so that one could be used in case of a 
severe failure. Recommend to the SSG that the priority be lowered to 4. 


E.21 Symptom: LeRC Transmit to ARC Dropped 
Problem report #21 Opened: 26 Mar 86 
Submitted: A1 Ross (x6519) Closed: 26 Mar 86 

NAS SPR #NEW, severity: 1 Assigned: Cmaylo 

Hypothesis: Bad Satellite connection 
Actions: 

(1) 7:35am, A1 Ross detected no LeRC transmit signal. He notified MSFC and 
Bohden Cmaylo. 

(2) 9:25am, 26Mar86: A1 Ross called and said the problem should be resolved. 
Bohden Cmaylo tried to "rlogin lerc" and was unable. The ARC2 Vital ink VB/1 needed 
rebooting for communication to resume. The problem at LeRC was twofold, 1) High 
winds moved the satellite dish and 2) There was an excessive temperature ( ~ 1 00 
degrees F) within the RF shelter. The dish was realigned and the backup air condi- 
tioner was turned on. Problem is closed. 
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